Date: Sun, 3 Feb 2013 17:46:24 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, current@freebsd.org Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130203164624.GL80850@alchemy.franken.de> In-Reply-To: <20130203161145.GQ2522@kib.kiev.ua> References: <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de> <20130203161145.GQ2522@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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()? Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130203164624.GL80850>