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