Subject: [linux-audio-dev] Re: More results and thoughts on disk writing performance
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Apr 21 2000 - 03:13:37 EEST
On Thu, 20 Apr 2000, Karl JH Millar wrote:
> 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).
please benchmark with 500 - 1000MB total datasize,
to get more accurate results.
Anyway I am running on 2.2.14-smp ( RH 6.2), therefore the fsync() slowdown
on very large filesizes if what I may experience in my tests.
(read Stephen's posts)
> 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.
As said before I tried it too, but with no luck.
> 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.
Although the single sync() is better than the separate fsync() / fdatasync(),
it performs slower than plain writes, with peaks of up to 30%.
> 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()).
It neither predicable with sync() too , since the metadata updates can disturb
the disk I/O quite a bit (just look at the hdrbench graphs)
>
> 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?
EXACTLY !
I am experiencing the same !
After Paul praised the preallocation so much, I decided to test it, and I
get about 20% performance slowdown over the case when running without
preallocation.
But the interesting thing is that when running in O_SYNC mode,
writing to preallocated files is much much faster, than in the no-preallocation
case. But still very inferiour to plain buffered/non preallocated writes.
I can't explain why we do experience the slowdown with preallocation.
Any thoughts ?
>
> 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.
Yes that would be nice to check,
I made a quick test running hdrbench with 30 read tracks and 1 write tracks,
running both in atime and noatime mode.
noatime performs a bit better (looking at the plotted graphs), but not
significantly.
> - 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.
that is for sure: a professional HD recording system should always have
one or more disks dedicated exclusively to audio.
> - 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.
No you are wrong here:
the audio thread requires higher priority because it nneds finer granularity,
(we want low-latency response from our HD recorder).
The audio thread releases the CPU during blocking write()s to the audio device,
giving the disk thread all the time it needs to perform large disk I/Os which
blocks the disk thread almost all the time.
Therefore you gain NOTHING (=zero disk performance increase) by giving the disk
thread higher priority than to the audio thread, except that the audio will
drop-out sometime.
Benno.
This archive was generated by hypermail 2b28 : Fri Apr 21 2000 - 03:36:45 EEST