WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] EPT: Only sync pcpus on which a domain's vc

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] EPT: Only sync pcpus on which a domain's vcpus might be running
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Fri, 18 Sep 2009 15:55:49 +0100
Cc: Xiaohui Xin <Xiaohui.xin@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Xin Li <xin.b.li@xxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Paul Durrant <paul.durrant@xxxxxxxxxx>
Delivery-date: Fri, 18 Sep 2009 07:57:01 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=wVPC+nGRkzK/s+tBsPquHrXKZqCyzIazctExAlfcfe4=; b=FcgHQzREsHcgUOptNcATd8mjExVq1CVczxO+h0N8bzV2/SmYOf6wZPbDIH8MHtAJR8 c+t791xU4V5D019QmISpLeduoFSWgWO9xldYHUkP+Q6Sp0SrJDbRXDGJA1mQV4ebEztP f0VAABFn49xAurQ3Wseo7Vac8lWTMgTxYMOMQ=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=v/iaqxNy4hjPZ1Y5UXTs4lmz1RAZbIYS6+beV6Vq6vUh7lFT4QGhWRMxP87Doz296r dTRLdinX8XHhKYLFJGb9A0bzcYbDQBOqEh/EPBaM8vywbJm24H50EkTJOkgMpOEELrCc 4zdGykNXTzTi8HBEUZOpI90gI1WJXxAPr7HvU=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6D947CD.152BD%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0909180209q4d0ee18ex65673f52ca1d9c9c@xxxxxxxxxxxxxx> <C6D947CD.152BD%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Sep 18, 2009 at 2:21 PM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> 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.

In theory, the memory handed back by the balloon driver shouldn't be
touched by the OS.  I think it would be OK if guess accesses to that
gfn space didn't fail for the guest giving up the pages; however, we
can't give the memory to another guest until we know for sure that the
first guest can't possibly access it anymore.  I think we should be
able to modify the balloon driver to "batch" some number of updates;
say, 1024 at a time.  Paul, any thoughts on this?

The other thing is the level of indirection -- we have to add a
parameter to set_p2m_entry() that says, "Don't sync this right away",
and then add another function that says, "Now commit all the changes I
just made".  That may take some thought to do correctly.

I think avoiding flush-all is still a good idea, as we have other
things like populate-on-demand and zero-page sweep doing lots of
modifications of the p2m table during boot that can't be batched this
way.  For example, the zero sweep *must* remove the page from the p2m
before doing a final scan to make sure it's still zero.  I suppose we
could scan a list of pages, remove them all from the p2m (taking the
flush-all), and then scan them again... but it seems like now we're
starting to get a lot more complicated than just keeping a mask or two
around.

Thoughts?

I think starting with a "flush-on-switch-to" would be good; it should
be fairly straightforward to make that flush happen only when:
* the domain has run on that cpu before, and
* the domain has had p2m changes since the last time it ran

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel