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