Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Feb 2013 19:17:43 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        arch@freebsd.org, jeff@freebsd.org, current@freebsd.org
Subject:   Re: Physbio changes final call for tests and reviews
Message-ID:  <20130203171743.GS2522@kib.kiev.ua>
In-Reply-To: <20130203164624.GL80850@alchemy.franken.de>
References:  <20130202163322.GA2522@kib.kiev.ua> <20130203155718.GA6204@alchemy.franken.de> <20130203161145.GQ2522@kib.kiev.ua> <20130203164624.GL80850@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--YyxSosoRaUW6PdRh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=2E for
> > > > the !x86 architectures. Another testing focus are the SCSI HBAs and=
 RAID
> > > > controllers which drivers are changed by the patchset. Please do te=
st
> > > > this before the patchset is committed into HEAD !
> > > >=20
> > > > The plan is to commit the patch somewhere in two weeks from this mo=
ment.
> > > > The patch is required for the finalizing of the unmapped I/O work f=
or UFS
> > > > I did in parallel, which I hope to finish shortly after the commit.
> > > >=20
> > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5=
=2Ediff
> > > >=20
> > >=20
> > > Once you bring in said UFS changes, will the use of bus_dmamap_load_c=
cb(9)
> > > be a requirement for disk controller drivers?
> >=20
> > Generally speaking, no. I plan to do the gradual migration of the drive=
rs,
> > 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.
> >=20
> > 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.
> >=20
> > My plan is to convert ahci(4) and then some often used high-profile dri=
vers
> > like mfi(4) and mps(4). I can also hope for isci(4) help.
> >=20
> > 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.
>=20
> Okay
>=20
> >=20
> > 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 commi=
tted.
>=20
> 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 <=3D 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().

--YyxSosoRaUW6PdRh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJRDpu2AAoJEJDCuSvBvK1By24P/Rp+VIMl++pMjg6C7/A5ed0I
AIZ70QQEPIekITd3AOj1UekTLUsYdGCoHT4ruSpJ3PNXIGyUqzUzVnsjR5sMHVzV
4PlHDEW6TFwm9MLs7mLio5hgQ7V0vj1yJMxhPyMhAD8lPk3sr40wUKIJM5VbT7B2
tli+sFag/J9Gq3kJ2LAROKaoYYD8dBczvP65xZgdQR/B2tWzdaUHQevaowGd8QNS
WfuafBivVMKy5PR6zRDzWJF8EuDedlwFNfnbQvCns/7OH65zJuEFql1P2P6Iir8U
vHWQRgo/Av8aIgTRIfptxQwCLDtlOzJKxKvgaYAQMDVF75oQhhoKRk5Zm4kfvZvR
bHszvl8qIx9jilKdmxdwK86kBSjxpg6Yr5DfeXklYvLL5kycrs60mYWvXwY/OK8A
HAXoXi1hwH8hka4G0lfHpCSKrHg7Q47fISwCUTkBa+sWpsnXk9VUipuSJb9tWpzd
+5h95ffeil4F56gKAHk1CC+rykN1kNuSbvoZpVRQCe/E467YjqXDJWV29c8IPoMs
dUY/p62IBSs8sZu3M62O0582CYzP2gto+zdQYgA9516YeJZYSku7DXbO15NmdlCG
wWzOIZ6nsIdUOt50/nmXgWKuqj0V3wh+tjNR8wz7P1uG0Kldrfy1QjFBdmGE+n2P
na1lt2H31/EYW8JmRgMy
=9bnf
-----END PGP SIGNATURE-----

--YyxSosoRaUW6PdRh--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130203171743.GS2522>