Messages in this thread |  | | Date | Tue, 12 Sep 2000 17:45:25 +0100 (BST) | From | Chris Evans <> | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |