Messages in this thread |  | | Date | Tue, 12 Sep 2000 19:35:15 +0200 | From | Martin Dalecki <> | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |