Subject: Re: [linux-audio-dev] [Fwd: [patch]2.4.0-test6 "spinlock" preemption patch]
From: Aki M Laukkanen (amlaukka_AT_cc.helsinki.fi)
Date: Thu Sep 07 2000 - 12:09:51 EEST
On Wed, 6 Sep 2000, Roger Larsson wrote:
> It is happening, a preemtable UP kernel.
> Current problems probably due to holding spinlocks
> for too long while walking linked lists etc.
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 - 13:07:36 EEST
