Subject: Re: [linux-audio-dev] disk i/o latency
From: Paul Sladen (paul_AT_sladen.org)
Date: Fri Sep 29 2000 - 23:17:48 EEST
On Fri, 29 Sep 2000, Kai Vehmanen wrote:
> On Fri, 29 Sep 2000, Benno Senoner wrote:
>
> >> I meant the lowlevel (kernel) implementation, ie. varience in
> >> read()/write() execution time.
> > that's a negligible time compared to the stalls I'm talking about.
>
> Uhm, those stalls are just the thing I'm after here. From apps point of
> view, they do appear to be caused by read()/write(), although the real
> cause is in the lowlevel filesystem buffers.
There's been an [entirely non thought-out] idea buzzing around in my head
as to whether some sort of API/ioctl should be added, possilibly to the
kernel, whereby it can be informed of the rate at which the Application
is going to "eat" the data, and thereby doing some sort of inteligent
cacheing to make sure that the data is going to already be in RAM by the
next time we do a "read()" on that particular stream/file.
Obviously when ever the stream is paused/stopped etc the kernel (or
low-level cacheing manager) would need to be informed that the
bytes-per-second "eat rate" has dropped to zero.
int rate = 48000*sizeof(float),
max = 12000*sizeof(float);
fd = fopen(..);
ioctl(fd, BYTE_EAT_RATE, &rate);
ioctl(fd, MAX_GOBBLE_SIZE, &max);
This would tell the kernel the how fast you intend to "eat" the stream,
and secondly, how much it should try and "gurantee" to have buffered ready
for collection by "read()" -- basically should you promise not to eat
more than this at one setting, if you do, it will probably have to fetch
it from disk.
Again it's not thought out, so I'm probably up the wrong tree, comments
people ?
Paul
OTOH, perhaps this should be in a low-level userspace library that we
should all subscribe to. -- Speed, and scheduling though.
._ ... . _._. ._. . _ __ . ... ... ._ __. . .. _._.
Paul Sladen paul_AT_sladen.org www.paul.sladen.org
The hardest thing in the world to understand is the
income tax. -- Albert Einstein
This archive was generated by hypermail 2b28 : Sat Sep 30 2000 - 00:05:45 EEST