[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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
>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
>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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.089 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site