[linux-audio-dev] More results and thoughts on disk writing performance

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] More results and thoughts on disk writing performance
From: Karl JH Millar (kmillar_AT_MIT.EDU)
Date: Thu Apr 20 2000 - 22:15:32 EEST


Benno,

I tried your benchmark on the linux systems I have available, and couldn't
reproduce the slow down you find using sync/fsync/fdatasync. There is some
overhead in the system calls themselves, which gave a few % performance loss,
but not your 30-60%. The only other difference I noticed on one disk that is
fairly full and fairly fragmented was more seeking using fsync() after each
write than under other methods, but even that only caused only a moderate
performance hit (maybe 10-15% if my drive was faster).

(BTW, I didn't try the multithreaded case, but it can't give better than a
few % performance increase)

What results do others get?

Given my results, it seems that the best method to
write data would be to do a group of write()s, and follow them with a sync(),
so we eliminate the bursty behaviour that was killing performance before.
Using a single call to sync instead of running fsync() on every file descriptor
saves a little kernel time, and allows the kernel to choose what order to write
the data.
On my machine at least, this gives us everything we need - close to maximal
throughput (unlike O_SYNC) and predictable behaviour (which we don't get
without calling sync()).

Incidently, on the systems I tested it appears that preallocation *slows down*
data writing. Paul, have you compared your system with and without using
preallocation? What speed difference do you see?

Random other things that may help getting optimal disk throughput:
       - Mounting the file system using the noatime flag. Then at least
         reading data doesn't force the metadata to be updated, which
         should help a little.
       - Swap should either be off or on a different drive so we don't have
         to worry about paging in the middle of intensive I/O.
       - Why are people giving the audio thread higher priority than the disk
         thread? In my mind it makes sense to have it the other way around,
         as the disk thread is going to block almost immediately anyway,
         whereas the audio thread may run for some time, during which we have
         no disk I/O going on. It seems to me to be better to start the disk
         I/O as soon as possible by giving it the higher priority. This could
         only cause problems if you try to write too much data at once,
         causing the thread not to block immediately, but this is easily
         avoided.

Any thoughts?

Karl.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Apr 20 2000 - 22:46:46 EEST