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
next prev parent 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.