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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:19 EST