Re: [Xen-devel] [RFC] linux: add p[mug]d_clear_full() accessors

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Jan Beulich wrote:
> > In fact, in pvops-Xen, I set PG_pinned on all pinned pagetable pages 
> > (not just the top level), so you can tell whether you're updating a 
> > pinned pgd/pud/pmd without needing an mm on hand.  So I think this 
> > optimisation can be implemented in current Linux entirely within the 
> > 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.
>   
Yes, 64-bit has masses of free page flags, so we could allocate new ones 
if need be.  But owner_priv_1 is definitely available for Xen's use, so 
it may as well be common (indeed, I'd expect all the existing code to 
just work on 64-bit at the moment, though perhaps its missing some 
4th-level pagetable stuff in places, and testing).
> 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.
I don't think so.  So long as its clear by the time you free the page, 
it doesn't matter how it gets used in the meantime (after all, you 
should never free a pinned pagetable page).
In general, almost all the page flags are available for our use in 
pagetable pages.  The pages are privately owned by Xen, and don't 
participate in any of the mm/ code, so there's no conflict if we use the 
bits for something else.  For example, in my Xen save/restore patches, 
I've overloaded PG_dirty to mean pinned-for-suspend, and there's no 
conflict with any other users.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel