Subject: Re: UBC, interactive performance, etc
To: Simon J. Gerraty <sjg@quick.com.au>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 04/10/2001 14:46:38
On Tue, Apr 10, 2001 at 02:14:05AM -0700, Simon J. Gerraty wrote:
>
> In case that's not clear, imagine that each time the system goes to accept 
> a write - it looks at the length out the write out queue, and if its less
> than some minimal length (or its length last time we looked) we accept
> the write, otherwise we block it.

Exactly.  This kind of implementation has some other nifty properties.  For
example, if you've got tasks that produce "optional" I/O, such as coalescing
files (or, in an extent-based filesystem, extents) or aggressively cleaning
an LFS or aggressively pushing delayed writes to disk, you can *ask* them
for more I/O requests (this is probably as simple as waking them up, getting
some number of transfers, and putting them to sleep) to keep the queue length
at your target when you notice that it's shorter than that.

However, to get this right you need either two queues or some notion of
"cancellable" requests.  Otherwise "optional" I/O can seriously delay real
I/O.  SGI has a white paper on using two queues for this kind of thing but
I think explicitly marking some requests as cancellable is a better idea.

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron