Re: Disk scheduling policy (Re: NEW_BUFQ_STRATEGY)

Alfred Perlstein <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel,gmane.os.netbsd.devel.performance
Message-ID <[email protected]>
* Jason Thorpe <[email protected]> [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 protected]>
> 



-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [email protected] cell: 408-480-4684
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.