Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Dec 2013 11:00:53 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Alan Cox <alc@rice.edu>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@FreeBSD.org>, src-committers@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org>
Subject:   Re: svn commit: r259908 - head/sys/vm
Message-ID:  <20131229090053.GU59496@kib.kiev.ua>
In-Reply-To: <52BF7195.2070606@rice.edu>
References:  <201312260546.rBQ5kAoJ009798@svn.freebsd.org> <52BF6699.1040006@freebsd.org> <52BF7195.2070606@rice.edu>

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

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

On Sat, Dec 28, 2013 at 06:49:25PM -0600, Alan Cox wrote:
> On 12/28/2013 18:02, Nathan Whitehorn wrote:
> > On 12/26/13 00:46, Marcel Moolenaar wrote:
> >> Author: marcel
> >> Date: Thu Dec 26 05:46:10 2013
> >> New Revision: 259908
> >> URL: http://svnweb.freebsd.org/changeset/base/259908
> >>
> >> Log:
> >>   For ia64, use pmap_remove_pages() and not pmap_remove(). The problem=
 is
> >>   that we don't have a good way (yet) to iterate over the mapped pages=
 by
> >>   virtual address and simply try each page within the range. Given tha=
t we
> >>   call pmap_remove() over the entire 2^63 bytes of address space, it t=
akes
> >>   a while for pmap_remove to have tried all 2^50 pages.
> >>   By using pmap_remove_pages() we use the PV list to find all mappings.
> >>  =20
> >>   Change derived from a patch by: alc
> >>
> > Why make this ia64-specific? It seems like a potentially useful general
> > optimization and certainly shouldn't be harmful on other architectures.
>=20
> Some of the other implementations of pmap_remove_pages() have
> limitations that don't permit them to be used for this purpose, e.g.,
>=20
>         if (pmap !=3D PCPU_GET(curpmap)) {
>                 printf("warning: pmap_remove_pages called with
> non-current pmap\n");
>                 return;
>         }

BTW, I do not easily see why the current amd64 implementation needs
the pmap being current.  I do not see accesses to recursive page table
mappings in the code.

--HrQ/+whymLRZ6Agu
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJSv+TFAAoJEJDCuSvBvK1BjDMP/R260PGrKF685fgY8O/3T/TX
iSFJor7IsJ7p+dZn3HN/RRIhezOrSI6YstklcvU+XYfGAjRLpdkY7xAB8ugzddmv
CRnGRtPrzizL3uMsPWWAvM47/hjV4w3nrE/AKuOJnLM2pPGx7VnRXTPrO66r6kS5
JigLu/PBHoQQ64EOn6V8w/+h0AI4HmFTIKNv3VD66Yfxlcyu55G5Kjxr2V+mqU6f
EYLLinCUF5qbVVFTGOpHTClE563DIpTH/dM6B36ZiaEjPswWRbwUAJafkiWB7WYt
AV9vO9/hb3lpPDHo44uXS2hAuVQ9HGxgYrwdbzR2HBFUZ9eS/lJDXhzHqeyUC/LY
ZjB+qBy5cuYNWXGqks8Wbe21FCRkTy3lQv7aYyTLw52i/wixq5eKC5XrYmgP2/G4
RDBj9wavXoGP7lDAVWXX1KUMtEdzt47nSL/cAce3q7CVSA8+O/5QgXSj0XswPk5v
5je4Sdpv/X89oa3jn9dOxOzsTBhx3DYhuVGhKskbX7SoJPqvYO5Ke2P/2X+Somw9
GSBKfjqUhV5i9yJd4MJbSDaxy+PrKGrfTKeJfU4Y2dSLT3IKRvNP4TJEIOSBlWSo
e9ciQ+W1gwIhB1Uc/+1PkeHAfgy5lCtKGZM+Sh+SN1yBo+DP7beebpImdHKth2pL
zHBtXzbrFL3XY1YgR5bD
=rj+C
-----END PGP SIGNATURE-----

--HrQ/+whymLRZ6Agu--



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