Subject: Re: [Fwd: [linux-audio-dev] info point on linux hdr]
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon Apr 17 2000 - 20:21:31 EEST
On Mon, 17 Apr 2000, Stephen C. Tweedie wrote:
>
> Of course not. You are doing sync IO in each case, and are doing it
> from a single thread.
>
> > Again I think O_DIRECT is the only way which will allow us to use smaller
> > buffers, but we will gain almost nothing in terms of total delivered MB/secs.
>
> No. O_DIRECT will gain you *nothing* in terms of IO scheduling over O_SYNC.
> The only thing O_DIRECT gains is zero-copy and zero-caching, which results
> in lower CPU utilisation.
>
> The only way you can get much better is to do non-writeback IO
> asynchronously. Use O_SYNC for writes, and submit the IOs from multiple
> threads, to let the kernel schedule the multiple IOs. Use large block
> sizes for each IO to prevent massive amounts of disk seeking. O_DIRECT
> in this case is not an instant win: it is completely orthogonal to the
> IO scheduling issue.
Hmm, interesting.
Are you suggesting to fire up multiple threads where each writes a couple of
files (in 256kb chunks) with O_SYNC ?
how many threads in you opinion ?
The reading thread: should that still be only one, in order to prevent seeking ?
Anyway I don't understand particularly well why multiple writers should buy us
anything, since the writing thread basically does nothing but issuing write()s
to disk. That's manual scheduling of write()s in user space (in 256k blocks).
Since the thread runs SCHED_FIFO (or nice(-20) ), it should be always
ready to issue new write() requests as soon as the disk finished the previous
one.
Or am I missing something ?
As for O_DIRECT: my idea was that it would prevent the cache getting in the way
thus avoiding the bursty IO behaviour, but I was not speaking about higher
performance and/or lower CPU utilization due to less/no memory copying overhead.
Anyway I think that O_SYNC in a single threaded model is very slow, and
even reading 256kbyte chunks you get only a fraction of the full disk
performance. Hopefully this is not true for O_DIRECT too, or it will be
unusable. (with O_SYNC I a mere 50-60% # of tracks compared to running without
O_SYNC).
O_SYNC or no O_SYNC, the problem is still the buffercache,
even when doing read only multitrack (no writes), the buffer utilization is
still high.
Benno.
>
> --Stephen
This archive was generated by hypermail 2b28 : Mon Apr 17 2000 - 21:23:42 EEST