Re: [Fwd: [linux-audio-dev] info point on linux hdr]

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

Subject: Re: [Fwd: [linux-audio-dev] info point on linux hdr]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Apr 17 2000 - 20:10:41 EEST


>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.

I had a question about this. Doug Gilbert told me that he heard using
multiple threads to schedule I/O requests could be a win, and that was
also my intuition. Other people have claimed that its often not a win,
and that the kernel's I/O scheduling algorithm is not well-suited for
the particular case in question here, making it better to just queue
them up serially by blocking a single thread in a read/write call.

If using multiple threads is a good idea, then how many is good ? I'm
guessing that 24 threads all submitting disk requests at almost
exactly the same time is not likely to be optimal, for example. Or is
it? I seem to recall a design like this that I actually coded and
tried, and it seemed slower than with a single serialized disk i/o
thread.

As for O_DIRECT, yes, its clearly orthogonal, but as BeOS points out
rather nicely, incredibly valuable when doing streaming media since it
doesn't (or shouldn't) pollute the buffer cache, which would be
pointless in this situation. This would also remove the buffer cache
batching write-behinds too, which would fix that problem for those who
suffer from it, no ?

--p


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

This archive was generated by hypermail 2b28 : Mon Apr 17 2000 - 20:41:13 EEST