All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [RFC] linux: add p[mug]d_clear_full() accessors
Date: Tue, 20 May 2008 16:54:11 +0100	[thread overview]
Message-ID: <48331043.76E4.0078.0@novell.com> (raw)
In-Reply-To: <4832EB8F.8010405@goop.org>

>>> 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 
>doesn't have mm_is_pinned().

Yes.

>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.

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

  reply	other threads:[~2008-05-20 15:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 14:42 [RFC] linux: add p[mug]d_clear_full() accessors Jan Beulich
2008-05-20 14:46 ` Keir Fraser
2008-05-20 15:17 ` Jeremy Fitzhardinge
2008-05-20 15:54   ` Jan Beulich [this message]
2008-05-20 20:03     ` Jeremy Fitzhardinge
2008-05-21  6:47       ` Jan Beulich
2008-05-21  9:02         ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48331043.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.