Subject: Re: Disk scheduling policy (Re: NEW_BUFQ_STRATEGY)
To: Jason Thorpe <firstname.lastname@example.org>
From: Alfred Perlstein <email@example.com>
Date: 12/01/2003 17:32:49
* Jason Thorpe <firstname.lastname@example.org> [031201 17:00] wrote:
> On Dec 1, 2003, at 4:56 PM, Thor Lancelot Simon wrote:
> >Unfortunately, this requires modifying every disk driver to handle
> >uber-bufs instead of bufs, no? It's highly similar to the change
> >that BSDI made long ago to chain buffers together through a pointer
> >in struct buf -- we could have whacked pagemove() much earlier if
> >we picked up that change, but we didn't because of the changes it
> >would have required in all of the disk drivers.
> Yes, it would require a change to disk controller drivers (not disk
> drivers; they enqueue/dequeue, but don't really "process" the bufs).
> But is that really so horrible?
> See what I said about adding a bus_dmamap_load_buf(); we could add this
> API call, and then such drivers would automatically pick up additional
> enhancements to the buf data representation mechanism.
This is one of the problem we face in FreeBSD. My suggestion would
be to have the disk driver register at load time whether or not it
can support the new bufs and have the kernel to the appropriate
thing, basically offer backwards compat for old drivers and map
the bufs and skip the large scatter gather support.
> -- Jason R. Thorpe <email@example.com>
- Alfred Perlstein
- Research Engineering Development Inc.
- email: firstname.lastname@example.org cell: 408-480-4684