On Tue, 12 Sep 2000, Hans Reiser wrote:
> I really think Rik has it right here. In particular, an MP3 player
> needs to be able to say, I have X milliseconds of buffer so make my
> worst case latency X milliseconds. The number of requests is the
> wrong metric, because the time required per request depends on disk
> geometry, disk caching, etc.
Hi,
We need to separate "what's a good idea" from "what's the best way to do
it".
Sure, it's a good idea to get an mp3 player's I/O request serviced within
a certain amount of time. Is the best way to do that hacking the concept
of time into the elevator algorithm? That's currently under debate.
In fact, the guarantee of I/O service time for a single process (mp3
player) is pretty orthogonal to the per-device elevator settings. If you
have a certain block device set to a max latency of 0.25s, and lots of
processes are hammering the disk, then something will have to give,
i.e. under heavy load this setting will be useless and not honoured.
The solution to this particular mp3 player scenario would be something
like the task scheduler policies we have. For example, maybe we could flag
a given process so that all it's I/O requests go to the head of the queue.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
