Subject: Re: Disk scheduling policy (Re: NEW_BUFQ_STRATEGY)
To: None <tls@rek.tjls.com>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
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--