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/
Home Products Support Community News


Re: [Xen-devel] Cpu pools discussion

To: George Dunlap <dunlapg@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Cpu pools discussion
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 28 Jul 2009 14:55:18 +0100
Cc: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 28 Jul 2009 06:55:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0907280641s50c618cweeac4484a8631ca6@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoPiRtroaBa9Xk1TOuC8ZvXsQckPAAAe7QQ
Thread-topic: [Xen-devel] Cpu pools discussion
User-agent: Microsoft-Entourage/
On 28/07/2009 14:41, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:

> As Juergen says, for people who don't use the feature, it shouldn't
> have any real effect.  The patch is pretty straightforward, except for
> the "continue_hypercall_on_cpu()" bit.

Just pulled up the patch. Actually cpupool_borrow_cpu() does not seem to
lock down the cpu-pool-vcpu relationship while continue_hypercall_on_cpu()
is running. In particular, it is clear that it does nothing if the vcpu is
already part of the pool that the domain is running in. But then what if the
cpu is removed from the pool during the borrow_cpu()/return_cpu() critical
region? It hardly inspires confidence.

Another thing I noted is that sched_tick_suspend/resume are pointlessly
changed to take a cpu parameter, which is smp_processor_id(). I swear at the
screen whenever I see people trying to slip that kind of nonsense in. It
makes it look like the functions can operate on an arbitrary cpu when in
fact I'll wager they cannot (and I doubt the author of such changes has
checked). It's a nasty nasty interface change.

 -- Keir

Xen-devel mailing list