> 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.
> 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
> 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
> 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.
No
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
