Messages in this thread |  | | Subject | Re: (reiserfs) Re: More on 2.2.18pre2aa2 | Date | Wed, 13 Sep 2000 00:47:57 +0100 (BST) | From | Alan Cox <> |
| |
> 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |