Messages in this thread |  | | Date | Tue, 12 Sep 2000 19:57:54 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
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/
|  |