Benno Senoner writes:
> ... 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.
Excellent!
> 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 thread mode. 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.
No, that's not what I'm talking about. I'm just talking about disk
performance. If you use regular fdatasync then you avoid letting the
kernel accumulate a huge queue of dirty writeback buffers in the
buffer cache. If you don't use synchronous writes, then your
writeback queue grows to the point that when the bdflush task
eventually decides to flush things out, it can clog the disk request
queues for a substantial period.
In other words, I was talking about the impact of your disk write
behaviour on the performance of _other_ threads. If you don't let the
writebehind queues grow too large, then you prevent other threads from
seeing large latencies in their own disk IOs (including reads). If
you are concerned about the latency of the application which is
writing the data in the first place, then obviously a multi-threaded
model where you acquire the data and write to disk in different
threads is the way to go.
> 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
Yes, I'll think about this a bit once I'm back home (I'm offline right
now).
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/