On Wed, 13 Sep 2000, Martin Dalecki wrote:
>Andrea Arcangeli wrote:
>>
>> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>>
>> >First of all: In the case of the mp3 player and such there is already a
>> >fine
>> >proper way to give it better chances on getting it's job done smooth -
>> >RT kernel sceduler priorities and proper IO buffering. I did something
>> >similiar
>> >to a GDI printer driver...
>>
>> Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger
>> than 128mbyte :) and then run in background `cp /dev/zero .` in the same
>> fs where your mp3 file out of cache is living. Then you'll see why a large
>> buffer is useless if there's none kind of I/O fair scheduling into the
>> elevator. Repeat the same test in 2.2.16 then.
>>
>> The I/O latency Hans was taking about for the mp3 player, is the time it
>> takes for the buffer to become empty.
>
>I was talking about *proper* buffering not necessary *big* buffers.
Specificate "*proper* buffering".
If your buffer is shorter than the size of the file (and as it's a buffer
it's intended to be shorter as your mp3 file can be several gigabytes
long), then at some point you'll have to page in from disk the new data to
refill the buffer.
What your proper buffering will do when linux doesn't complete the read
I/O to refill the buffer in time? (in time == before the buffer become
empty)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST