lkml.org 
[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: More on 2.2.18pre2aa2
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:

> 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.

How about a simple "cost metric" for each request? (Each individual
request gets X "points", plus Y per block. Make Y almost zero for HDDs and
tape drives etc., make X and Y equal for solid state storage, say.)

In terms of latency, I'd suggest we aim to keep the device in use all the
time we have outstanding requests: every time the device is ready to
accept a request, we feed it the "next" one in the queue; until it is free
again, requests pile up in the queue, being sorted, merged etc.

This should perform very well under light loads - requests just get passed
to the device as fast as they can be handled - and under very heavy loads
- we have a large queue in play, with plenty of scope for reordering,
merges etc.

> > > ...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.

With the metrics above, you should be able to calculate appropriate values
for X and Y to make the "cost" figures roughly correspond to actual times,
I think? The big question, of course, is what do you do when the queue
reaches the maximum - block the next process to make a request? Better,
block all but the highest "I/O priority" process? Then, I can go copying,
moving and deleting files left, right and centre without my MP3 player
ever skipping, which is nice :-)


James.

-
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/

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