Re: Disk scheduling policy (Re: NEW_BUFQ_STRATEGY)

On Dec 1, 2003, at 4:23 PM, Thor Lancelot Simon wrote:

> I thought I suggested this to you about a year ago and you were rather
> strongly opposed, due to the VM system tricks involved in the obvious
> way one would do this given the rest of our current implementation?  I
> am _definitely_ in favor of request coalescing in disksort.

I am only opposed to any solution that uses VM to perform the 
coalescing.  I would prefer that most of the requests issued with 
"struct buf" not be mapped into KVA at all (see yamt's patches that get 
us part of the way there); it's rather silly to map a page into KVA 
just so we can extract the PA of the page for DMA later.

This is why I suggested creating an uber-buf that contained a list of 
sub-bufs.  The uber-buf would contain the starting block # and the 
overall length, and the sub-bufs would describe the individual 
transfers that were gathered into the uber-buf.  You could even use the 
normal bufq linkage (or a TAILQ union over it) to hook the sub-bufs 
into the uber-buf.

         -- Jason R. Thorpe <[email protected]>