Subject: Re: Disk scheduling policy (Re: NEW_BUFQ_STRATEGY)
To: None <tls@rek.tjls.com>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-perform
Date: 12/01/2003 16:29:38
--Apple-Mail-18--324017880
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


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 <thorpej@wasabisystems.com>


--Apple-Mail-18--324017880
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/y9zzOpVKkaBm8XkRAkJVAKDQz6js6tmvZPsJQyA1nGhgdwDwWgCdFN0w
she47QHbGLFJgnILDW13m68=
=Czxy
-----END PGP SIGNATURE-----

--Apple-Mail-18--324017880--