Messages in this thread |  | | Date | Tue, 12 Sep 2000 17:21:20 -0700 | From | Mitchell Blank Jr <> | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 |
| |
Alan Cox wrote: > > 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. > > Your perceived latency is based entirely on A.
Yes, but "how hard is it reasonable for the kernel to try" is based on both items. A good first order approximation is number of requests.
> > 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 > > I dont suggest you do queue limiting on that basis. I suggest you do order > limiting based on time slots
It's still a queue - the queue of things we're going to take on this elevator swipe, right? And the problem is one of keeping a sane watermark on this queue - not too many requests to destroy latency but enough to let the elevator do some good.
> > Well, actually just about any communications protocol worth its salt > > uses some sort of windowing throttle based on the amount of data > > Im talking about flow control/traffic shaping
...where the user sets a number exlpicitly for what performance they want. Again, if we're going to make the user set this latency variable for each of their devices, then doing it based on time will work great.
> > 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 > > The same argument is equally valid for the current scheme, and I think you'll > find equally bogus
There will always need to be tunables - and it's fine to say "if you've got oddball hardware and/or workload and/or requirements then you should twiddle this knob". But it seems to me that the current scheme works well for a pretty big range of devices. If you do the setting based on time, I think it'll be a lot more sensitive since there's nothing that will scale based on the speed of the device.
-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/
|  |