Messages in this thread |  | | Date | Tue, 12 Sep 2000 16:47:45 -0700 | From | Mitchell Blank Jr <> | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
Alan Cox wrote: > > Now, I see people trying to introduce the concept of elapsed time into > > that fix, which smells strongly of hack. How will this hack be cobbled > > Actually my brain says that elapsed time based scheduling is the right thing > to do.
No, Andrea is right here. The argument that everyone is using ("Our target - latency - is measured in time") is utterly bogus. Yes, it's measured in time, but remember that there are two things measured in time here: A. The time for the whole queue of requests to run (this is what Rik is proposing using to throttle) B. The time an average request takes to process.
If we limit on the depth of queue we're (to some level of approximation) making our decision based on A/B. It's still a magic constant, but at least it's scaled to take into account the speed of the drive. And underneath, it's still based on time.
> It certainly works for networks
Well, actually just about any communications protocol worth its salt uses some sort of windowing throttle based on the amount of data outstanding, not the length of time it's been in the queue. Which is why TCP works well over both GigE and 28.8. [*] Now substitute "big fiberchannel RAID" for GigE and "360K floppy" for 28.8 and you've got the same problem.
* -- Yes, for optimal TCP over big WAN pipes you may want to use a larger buffer size, but that's a matter of the bandwidth delay product, which isn't relavent for talking about storage
If we move to a "length of queue in time" as Rik suggests then we're going to have to MAKE the user set it manually for each device. There's too many orders of magnatude difference between even just SCSI disks (10 yr old drive? 16-way RAID? Solid state?) to make supplying any sort of default with the kernel impractical. The end result might be a bit better behaved, but only just slightly. If people absolutely need this behavior for some reason, the current algorithm should stay as the default.
-Mitch - 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/
|  |