[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: (reiserfs) Re: More on 2.2.18pre2aa2
Alan Cox wrote:
> > 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.
> I must strongly disagree with that claim. A request could be 512 bytes or
> 128K.

Yeah, as sct pointed out this gets thorny. For a modern harddrive this
probably doesn't matter (since sequential I/O is SO fast compared to
seek times) but for other devices its an issue.

> > ...where the user sets a number exlpicitly for what performance they
> > want. Again, if we're going to make the user set this latency
> No they do not. The parameters are defined by the bandwidth and measured
> behaviour.

Hmmm... well if someone wants to propose an algorithm to self-tune the
"queue depth in milliseconds" number then maybe we'll get somewhere.
You'd need to do some sort of moving averages of both requests/sec and
sectors/sec that come out of the elevator and use those as feedback to
adjust the queue-depth-value. I'm not sure if this is advisable, but
at least it sounds feasable.

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.142 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site