Subject: RE: Coallesce disk I/O
To: None <tls@rek.tjls.com>
From: Gordon Waidhofer <gww@traakan.com>
List: tech-perform
Date: 01/26/2004 21:29:13
I did spend a couple of hours (that I didn't have)
looking into the driver changes, et al. That rabbit
hole goes mighty deep :)

Disksort() should be coallescing friendly, I think.
When there is channel capacity, the buf queue can
be scanned according to a set of constraints (max
transfer size, DMA slots, etc). That's what I meant
by "Just In Time" coallescing.

JITC? Doesn't roll of the tongue, does it.

So, disksort shouldn't coallesce per-se. It
should just make coallescing at the right time
easier.

As you say, the rub is all the data structures
for DMA setup. For example, the SCSI request has
but one dataprt/datalen pair. Changing the request
structure means a tear-up of a helluva lot of code.

Mighty deep rabbit hole.

Definitely consensus on what's to be done
should be built before building anything else.

I highly recommend, as part of this train of
thought, reviewing Seltzer's paper "Disk
Scheduling Revisited", about 12 year ago.
At first look it'll seem tepid. But give it
a chance. There's a lot of insight there.
Pay particular attention to the loads measured.
It takes a huge load before the "exotic" head
schedulars matter.

Cheers,
	-gww


> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of Thor Lancelot Simon
> Sent: Monday, January 26, 2004 8:36 PM
> To: Gordon Waidhofer
> Cc: tech-perform@NetBSD.org; tech-kern@NetBSD.org
> Subject: Re: Coallesce disk I/O
> 
> 
> On Mon, Jan 26, 2004 at 07:51:26PM -0800, Gordon Waidhofer wrote:
> > 
> > Coallescing I/O isn't going to do anything about softdep
> > bugs. I just wanted to start a thread since there was
> > discussion about performance under heavy load.
> > It's been good. Nothing urgent, though.
> 
> FWIW, I see no reason that disksort couldn't build something
> like the buffer chains that BSD/OS used to use to do FFS
> clustering without the awful pagemove() hack.  Several people
> have proposed this, or its equivalent.  The thing is, nobody's
> seemed willing to go define such an interface and whack it into
> the various disk drivers; making disksort actually merge is
> by far the easy part.
> 
> Generally, our I/O subsystem needs to get smarter about several
> facets of request handling.  The N of us who've picked up
> per-device MAXPHYS but never finished it are all on the hook for
> some of that... :-)
> 
> -- 
>  Thor Lancelot Simon	                                      tls@rek.tjls.com
>    But as he knew no bad language, he had called him all the names of common
>  objects that he could think of, and had screamed: "You lamp!  You towel!  You
>  plate!" and so on.              --Sigmund Freud