From: Andrew Theurer <habanero@us.ibm.com>
To: "Mike D. Day" <ncmike@us.ibm.com>
Cc: Zachary Amsden <zach@vmware.com>,
Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
xen-devel@lists.xensource.com, Andi Kleen <ak@suse.de>,
virtualization@lists.osdl.org
Subject: Re: turn off writable page tables
Date: Wed, 09 Aug 2006 16:15:09 -0500 [thread overview]
Message-ID: <44DA505D.2080209@us.ibm.com> (raw)
In-Reply-To: <20060803204205.GA29014@mdday.raleigh.ibm.com>
Mike D. Day wrote:
> On 02/08/06 10:21 +0100, Keir Fraser wrote:
>
>> I wonder how it will interact with our late-pin/early-unpin model
>> where we can directly write to pagetables before they are first used
>> and also while they are being finally destroyed. It may be that if we
>> use explicit batching and turn off that pinning logic we will not
>> affect performance much, but we'll need to do some performance analysis.
>
> Where are we on Andrew's Patch now? I think Andrew's Patch is a good
> solution for the time being until we can get batching, which may be
> too disruptive for 3.03.
> Mike
I would agree :) Honestly, there's does not appear to be any evidence
that batching of PTE updates, on typical applications, appear to have
any performance advantage, but the current batching implementation does
hurt scalability, and what really worries me, keeping it means keeping
around a lot of code in xen mm that has to catch coherency issues (all
the cleanup_writable_pagetable() calls and similar checks). I rather
have writable PTs removed completely now (and assume they don't come
back), then add explicit batching/multi-calls to specific parts of the
guests' kernels (which should not require extra code in Xen mm like the
coherency checks for writable PTs) -and only if they show to benefit
from it.
-Andrew
next prev parent reply other threads:[~2006-08-09 21:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 15:51 [PATCH] turn off writable page tables Ian Pratt
2006-07-28 16:31 ` Keir Fraser
2006-07-28 21:36 ` Zachary Amsden
2006-07-28 23:05 ` Andi Kleen
2006-07-28 23:10 ` Zachary Amsden
2006-07-31 9:14 ` Keir Fraser
2006-07-31 9:32 ` Zachary Amsden
2006-07-31 9:53 ` Keir Fraser
2006-07-31 19:56 ` Zachary Amsden
2006-07-31 22:07 ` Keir Fraser
2006-07-31 22:40 ` Zachary Amsden
2006-08-02 9:21 ` Keir Fraser
2006-08-03 20:42 ` Mike D. Day
2006-08-09 21:15 ` Andrew Theurer [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-07-27 17:31 [PATCH] " Ian Pratt
2006-07-28 8:55 ` Keir Fraser
2006-07-28 15:21 ` Andrew Theurer
2006-07-28 23:23 ` Mike Day
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=44DA505D.2080209@us.ibm.com \
--to=habanero@us.ibm.com \
--cc=ak@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=ncmike@us.ibm.com \
--cc=virtualization@lists.osdl.org \
--cc=xen-devel@lists.xensource.com \
--cc=zach@vmware.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.