Subject: Re: [linux-audio-dev] [Fwd: [patch]2.4.0-test6 "spinlock" preemption patch]
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Sep 07 2000 - 15:04:30 EEST
On Thu, 07 Sep 2000, Aki M Laukkanen wrote:
Aki, please note that you are talking about filesystem latencies, while
Roger is talking about schduling latencies.
In the case of latencytest, the app blocks on write() to /dev/dsp when
the audio buffer is full, and wakes up again, ass soon as there is one fragment
in the buffer available.
In the case of hdrbench, the diskthread issues read() and write() statements
and the graph shows how much data is available in the large ringbuffer.
From this value you can estimate the latency of the disk streaming engine.
eg: if you have 30 input and 30 output tracks (60 in total), then
if the average latency of hdrbench is around 300msec, then it means
that each track produces in mean about ( 300/60msec = 5msec latencies),
but as said these are mean values, sometimes it takes 100msec and sometimes
perhaps 1msec due to the caching.
The low-latency patches only help to hdrbench's audiothread to not dropout.
(the audiothread reads a fragment form the ringbuffer (lock-free fifo) and
writes the data to /dev/dsp)
So what's relevant in hdrbench's case is only the efficiency of the disk buffer
cache (bdflush) , the elevator, the read ahead/write behind mechanisms of the
OS, the VM (if the VM begins to swap like mad, it can kill the streaming
performance for a moment, therefore the large buffers I use in hdrbench) and the
disk performance of the disk hardware.
Regular linux kernels experience scheduling latency peaks of about
50-100msec, and even a non-low-latency kernel can perform well
when running hdrbench provided that the disk-related stuff
(filesystem,elevator,bdflush,VM etc) works well.
And yes your graph looks MUCH better than mine
(eg: http://www.linuxdj.com/hdrbench/graph-18-18.gif on a IBM16GB EIDE ext2
with 1024byte blocks)
Keep in mind that blocksizes of 1024 on the ext2 filesystem perform very poorly
compared to blocksizes of 4096 bytes.
Some suggestions for your filesystem:
if you can, disable the caching , write-behind and read-ahead completely.
HDR software will read and write data in large blocks (eg 256KB) and since
we stream the data, caching is useless, because the data does not get reused.
Basically what we need is a sort of direct IO.
As for fragmentation, I believe that this is not THAT a big factor, because
when streaming multiple tracks we have to seek after each block (256KB) anyway,
thus as long the fragments are in the range of the blocksize (256KB) it does
not matter if the file is continuous or fragmented.
thoughts ?
cheers,
Benno.
>
> Btw. the current problems with latency in context of what the user
> application sees, seem to be a lot more vm oriented than due to long code
> paths in kernel. I've done quite a lot of testing with streamfs this week,
> see for example:
>
> http://www.cs.helsinki.fi/u/amlaukka/streamfs/hdrbench32x30-blk1.png
>
> There are 32 input tracks and 30 output tracks in this test. Kernel is stock
> test8-pre1 with Jens' blk-1 patch (fixes elevator problems but this seems
> not to matter much). The huge spikes in the figure seem to be due to paging
> activity which indicates that vm is quite fragile in case of streaming I/O.
>
> I haven't got a dedicated hard disk for the streamfs partition which could
> help somewhat in this situation though. I've also tried various low latency
> patches which did not help a squat. The baseline latency, around 250ms if I
> calculated correctly (10000 samples), I'm not entirely sure about. According
> to sard, each request is serviced on average in about 250-400ms. I haven't
> gotten over the hdrbench benchmark in details to see if it contributes
> somehow. Tweaking the elevator might prove worthwile.
>
> I've implemented a bit of a hack for "directo I/O" like semantics but this
> seemed to make no difference. My next step is to forcefully free the pages
> on b_end_io. I need to do more testing with Rik's multiqueue vm too. Initial
> testing was not promising.
>
> --
> D.
This archive was generated by hypermail 2b28 : Thu Sep 07 2000 - 14:29:26 EEST
