Chris Evans wrote:
>
> 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
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...
Second: The concept of time can give you very very nasty behaviour in
even
cases. Assume that a disc can only do 1 request per second. And then
imagin
a sceduling based on a 1+epsilon second... basically the disc will be
run
with half the speed it could. Those nasty integer arithmetics can you
catch easly
and mostly allways entierly unexpecting.
Third: All you try to improve is the boundary case between an entierly
overloaded system and a system which has a huge reserve to get the task
done.
I don't think you can find any "improvement" which will not just improve
some
cases and hurt some only slightly different cases badly. That's
basically the
same problem as with the paging strategy to follow. (However we have
some
kind of "common sense" in respect of this, despite the fact that linux
does ignore
it...)
Firth: The most common solution for such boundary cases is some notion
of
cost optimization, like the nice value of a process or page age for
example, or
alternative some kind of choice between entierly different strategies
(remember
the term strategy routine....)
- all of them are just *relative* measures not absolute time constrains.
Fifth: I think that such kind of IO behaviour control isn't something
generic enough for the elevator - it should be all done on the
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.)
--
- phone: +49 214 8656 283
- job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
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/
