From: "Jan Beulich" <jbeulich@novell.com>
Subject: Re: [RFC] linux: add p[mug]d_clear_full()
	accessors
Date: Tue, 20 May 2008 16:54:11 +0100
Message-ID: <48331043.76E4.0078.0@novell.com>
References: <4832FF91.76E4.0078.0@novell.com> <4832EB8F.8010405@goop.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <4832EB8F.8010405@goop.org>
Content-Disposition: inline
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com

>>> Jeremy Fitzhardinge <jeremy@goop.org> 20.05.08 17:17 >>>
>Is this based on your forward-port of the Xen patches?  Stock 2.6.25.4=20
>doesn't have mm_is_pinned().

Yes.

>In fact, in pvops-Xen, I set PG_pinned on all pinned pagetable pages=20
>(not just the top level), so you can tell whether you're updating a=20
>pinned pgd/pud/pmd without needing an mm on hand.  So I think this=20
>optimisation can be implemented in current Linux entirely within the=20
>Xen-specific code.

Ah, I didn't realize that so far. However, 64-bit doesn't use a PG_*
flag for identifying pinned mm-s, because of a conflict in use of
PG_arch_1 in those older kernel versions. But as the conflict is gone
in recent kernel, I should indeed be able to synchronize 64-bit with
32-bit here, then follow your approach of marking all pinned page
tables, and finally get away without adding a new set of abstractions.

One question though - in our 2.6.23 merge (where pv-ops-Xen's
PG_pinned appeared as an alias of PG_owner_priv_1, and where
PG_arch_1 got assigned a meaning for native x86, so PG_pinned
for the traditional patches needed to change anyway) I intentionally
didn't follow pv-ops for our patches, since PG_pinned is among the
flags bad_page() checks for (in the XenSource tree, and I think this
should really also be done in upstream Linux), and hence re-using
the bit here would change behavior for other parts of the kernel.

Jan