Subject: RE: Coallesce disk I/O
To: None <email@example.com>
From: Gordon Waidhofer <firstname.lastname@example.org>
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
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
> -----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 email@example.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