Messages in this thread | | | Date | Wed, 13 Sep 2000 14:02:57 +0100 (BST) | From | James Sutherland <> | Subject | Re: (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/
| |