From: Keir Fraser <keir.fraser@eu.citrix.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Tim Deegan <Tim.Deegan@eu.citrix.com>,
Xiaohui Xin <Xiaohui.xin@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Xin Li <xin.b.li@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: Re: [PATCH] EPT: Only sync pcpus on which a domain's vcpus might be running
Date: Fri, 18 Sep 2009 14:21:01 +0100 [thread overview]
Message-ID: <C6D947CD.152BD%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <de76405a0909180209q4d0ee18ex65673f52ca1d9c9c@mail.gmail.com>
On 18/09/2009 10:09, "George Dunlap" <dunlapg@umich.edu> wrote:
> Just making sure I understand the failure mode... the risk is that if
> we change the p2m for this domain while a vcpu is not running on that
> core, and it's scheduled there again, it may have stale mappings that
> get used (tagged by the EPT base pointer).
Correct.
> Hmm... any idea the performance implications of flushing the EPT
> mappings when switching out? The main performance problem I need to
> fix is the ballooning case. Without this patch, on my 2x4x2 Nehalem
> box, a single-vcpu guest ballooning from 16GiB down to 8GiB for an
> initial boot takes 12-15 minutes; with the patch, it takes around 40
> seconds.
How bad is it is you don't flush at all? 40s is still not great and maybe we
could batch the INVEPT invocations? That might also greatly reduce the cost
of the current naïve flush-all implementation, to a point where it is
actually acceptable.
> Perhaps we could start with the flush-ept-on-context-switch-out, and
> do some performance testing later to see if it's worth maintaining a
> "might-need-an-ept-flush" mask.
Well, that's a possible alternative, yes. Just needs a bit of care in
implementation but it wouldn't need much extra code.
-- Keir
next prev parent reply other threads:[~2009-09-18 13:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-17 17:51 [PATCH] EPT: Only sync pcpus on which a domain's vcpus might be running George Dunlap
2009-09-18 7:43 ` Keir Fraser
2009-09-18 9:09 ` George Dunlap
2009-09-18 13:21 ` Keir Fraser [this message]
2009-09-18 14:55 ` George Dunlap
2009-09-18 16:51 ` Paul Durrant
2009-09-18 17:06 ` Dan Magenheimer
2009-09-19 10:34 ` Keir Fraser
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=C6D947CD.152BD%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=Tim.Deegan@eu.citrix.com \
--cc=Xiaohui.xin@intel.com \
--cc=dunlapg@umich.edu \
--cc=jun.nakajima@intel.com \
--cc=xen-devel@lists.xensource.com \
--cc=xin.b.li@intel.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.