[lkml]   [2000]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: (reiserfs) Re: More on 2.2.18pre2aa2
> 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.


> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.128 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site