This is not a problem for me, since using mingo's patches
(with some resceduling hookups at critical parts of the kernel),
I'm now able to run a thread which does no disk I/O, only audio output
and reading from a shared buffer with rock solid latencies <4ms, regardless of
disk I/O load.
Since I use a two threaded model, one doing only disk I/O and writing/reading to
ring buffers running at lower priority, and the audio thread running at
SCHED_FIFO max priority, it works fine.
> The way to get best streaming write performance here is to preallocate
> the data in advance (NOT just ftruncate(), which extends the file but
> doesn't allocate disk blocks --- do a real write() of NULLs to the
> file in advance). If you don't do that then you'll end up incurring
> extra disk seeks when you f*sync(), as you need to update lots of
> file metadata as a result of allocating new disk blocks. If you keep
> the fdatasync()s relatively infrequent (say, once every 500--1000ms)
> then the overhead of not preallocating the blocks shouldn't be too bad.
Maybe you meant that fdatasync() will keep latency low in a single threaded
model, but these latencies are way too big , and the only solution is the 2
The problem is that when you do harddisk recording, in some cases,
you don't know in advance the length of the recording, therefore you must write
to the disk dynamically without prealloc or writing NULLs to the file,
even if you have to sacrifice a bit of performance.
PS: Stephen did you look at my other mail about the problem that streaming of
large disks from disk (especially reading) throws all other files/executable out
of the filebuffers and makes the rest of fileops quite slow (when launching an
app several times, the 2nd is slow since the kernel has to re-load from disk),
it makes you feel like running on an unbuffered disk.
I'd suspect that all disks will feel as UNBUFFERED disks, due to streaming
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/