All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.