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.
>device driver level, if at all. In fact you have already bad
>interactions between strategies of low level drivers and the high
>level code in Linux - like for example the "get from top of queue" or
>"don't get it from top of the IO queue" mess between
>IDE and SCSI middlelayers... (However this got a bit better recently.)
That's historic cruft, it's unrelated to controlling the elevator
algorithm per-task/per-file basis IMHO.
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:19 EST