Re: Physbio changes final call for tests and reviews

On Sun, Feb 03, 2013 at 05:46:24PM +0100, Marius Strobl wrote:
> On Sun, Feb 03, 2013 at 06:11:45PM +0200, Konstantin Belousov wrote:
> > On Sun, Feb 03, 2013 at 04:57:18PM +0100, Marius Strobl wrote:
> > > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote:
> > > > Hi,
> > > > I finished the last (insignificant) missed bits in the Jeff' physbio
> > > > work. Now I am asking for the last round of testing and review, esp. for
> > > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID
> > > > controllers which drivers are changed by the patchset. Please do test
> > > > this before the patchset is committed into HEAD !
> > > > 
> > > > The plan is to commit the patch somewhere in two weeks from this moment.
> > > > The patch is required for the finalizing of the unmapped I/O work for UFS
> > > > I did in parallel, which I hope to finish shortly after the commit.
> > > > 
> > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff
> > > > 
> > > 
> > > Once you bring in said UFS changes, will the use of bus_dmamap_load_ccb(9)
> > > be a requirement for disk controller drivers?
> > 
> > Generally speaking, no. I plan to do the gradual migration of the drivers,
> > definitely not forcing the unmapped bios down to the drivers which are
> > not tested yet. In the patch, driver indicates the support for unmapped
> > bios by a DISKFLAG. If flag is set, driver could receive both mapped
> > and unmapped bios, and use of the bus_dmamap_load_ccb(), while formally
> > is only convenience, is essentially the requirement.
> > 
> > If driver does not set the flag, it receives the same i/o requests as
> > it does now. Geom performs transient compat mapping for the unmapped
> > requests on its own for such drivers. As result, driver does not need
> > a change.
> > 
> > My plan is to convert ahci(4) and then some often used high-profile drivers
> > like mfi(4) and mps(4). I can also hope for isci(4) help.
> > 
> > Everything else, IMO, could be done on the best efforts basis, when both
> > developers time and testing facilities are available. Jeff wanted to do
> > all driver conversion in one pass, but IMO this is unrealistic. Still, I
> > started write some helpers which should provide the transient one-page
> > mappings for PIO modes.
> 
> Okay
> 
> > 
> > You can look at some previous version of the unmapped patch at
> > http://people.freebsd.org/~kib/misc/unmapped.8.patch. It only contain a
> > hack for ahci(4), which should be fixed properly after physbio is committed.
> 
> Hrm, the changes to the sparc64 pmap code in the latter patch might
> need some more attention as some of the functions used for copying
> pages there IIRC have constraints on the aligment of source and
> destination as well as on the count. Can you say something about
> these properties when pmap_copy_page_offs() is called via
> pmap_copy_pages()?

There is no constraints on the offsets or length for the
pmap_copy_pages() itself. As a consequence, the only (obvious)
constraint is that cnt <= PAGE_SIZE for sparc64 pmap_copy_page_offs(). I
will be glad to obtain the help, both as advise and patch, for any !x86
architecture. For x86 too.

Yes, pmap_copy_pages() is the corner-stone of the data moves needed
when operating on the unmapped buffers. Our current i/o path already
converts user buffers into the page list, but it was enough to use
uiomove_fromphys() so far, because buffers were always mapped. Now,
unmapped buffers provide the other side of the copy with the page list,
so I need operation like pmap_copy_pages().