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 - 15:54:42 EEST
On Thu, 7 Sep 2000, Benno Senoner wrote:
> 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)
What I said that vm is very fragile, is not perhaps best seen in that graph.
There are better and worse runs. For example on some repeat I can get
behaviour which very much looks like what is in your graph. In that case
interactive performance seems to go down the toilet too. Mouse pointer
doesn't move etc.
Hmm. I must admit that I didn't look very carefully what exactly your
benchmark was measuring and how it relates to audio apps. I'm now
enlightened. :) It should still prove very beneficial if the audio buffer
sizes could be made smaller and interactive performance is always a
priority. 62 tracks take 62MB afterall which is mlocked.
> Keep in mind that blocksizes of 1024 on the ext2 filesystem perform very poorly
> compared to blocksizes of 4096 bytes.
Btw. I thought mkfs.ext2 nowadays uses blocksize of 4096 by default.
> Some suggestions for your filesystem:
> if you can, disable the caching , write-behind and read-ahead completely.
Within a filesystem disabling all these would mean duplicating most of
fs/buffer.c code. In my simple prototype, I've added a new inode flag
and modified the generic code. I think sct has plans for the real
implementation in 2.5 timeframe.
> 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.
Hmm. I'm not completely following you. Why would you have to seek after each
256kB write? These writes are anyway broken in to fs blocksize pieces and
given to the block device layer (ll_rw_block). Then elevator and the block
layer code try to merge these requests into bigger ones which are issued
on the disk. This can only be done if each request is held in the queue for
some time to wait for incoming requests and the requests are physically
adjacent. Hence, tunable variables elevator read and write latency.
Optimal case is of course that every incoming request can be merged until
the request has aged and one huge request is given to the block device
drivers. This why streamfs interleaves the tracks together. On ext2 fs there
is no guarantee of the physical placement of the disk blocks. I think the
block allocation strategies are optimized so that blocks within a file
should be close to eachother but not with respect to other files. Disk seeks
are not particularly cheap (possibly over 10ms) and thus should be minimized.
I've not completely validated that it works currently as I wish it would but
sard indicates large part of the requests are merged.
-- D.
This archive was generated by hypermail 2b28 : Thu Sep 07 2000 - 16:45:53 EEST
