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] [PATCH] xen: migrate vcpus only when needed

To: Ryan Harper <ryanh@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen: migrate vcpus only when needed
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 15 Apr 2006 10:10:29 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 15 Apr 2006 02:10:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of "Fri, 14 Apr 2006 16:10:49 CDT." <20060414211049.GN16776@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Currently, when pinning vcpus, the target vcpu is migrated to the first
> bit in the new cpumask even if the vcpu's current process is included in
> the new mask.  This produces a non-obvious side-effect when pinning
> vcpus.

How is that non-obvious? You specify a set of CPUs on which you are
happy for that VCPU to run and Xen may run the VCPU on any of those
CPUs at any time. The current implementation's decision to change
the CPU binding the moment you specify the set of CPUs, and always
choose the lowest one, is perfectly reasonable given the specification
of that interface.

 -- Keir

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

<Prev in Thread] Current Thread [Next in Thread>