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: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Cpu pools discussion
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 30 Jul 2009 14:18:00 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, George Dunlap <dunlapg@xxxxxxxxx>, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 30 Jul 2009 06:18:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A71976A.8040704@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: AcoRFIWJqG1UzuXvQEi6P2D5otsDBAAA6OS1
Thread-topic: [Xen-devel] Cpu pools discussion
User-agent: Microsoft-Entourage/
On 30/07/2009 13:51, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>> I think especially if cpupools are added into the mix then this becomes more
>> attractive than the current approach. The other alternative is to modify the
>> two existing problematic callers to work okay from softirq context (or not
>> need continue_hypercall_on_cpu() at all, which might be possible at least in
>> the case of CPU hotplug). I would be undecided between these two just now --
>> it depends on how easily those two callers can be fixed up.
> I'll try to set up a patch to add a hypervisor domain. Regarding all the
> problems I got with switching cpus between pools (avoid running on the cpu to
> be switched etc.) this solution could make life much easier.

I'm inclined actually to think a hypervisor domain is not necessary, and we
can get by with softirqs. I actually think cpu offline can be reimplemented
without softirqs or continue_hypercall_on_cpu(), and I would imagine cpupool
changes then could use a similar technique. I will take a look at that, and
you can take your cues from it if I find an elegant solution along those

> And George would be happy to see all the borrow cpu stuff vanish :-)

Yes, well I think we can get rid of that, regardless of a decision regarding
hypervisor domains. And we get rid of vcpu_lock_affinity too, which is nice.

 -- Keir

Xen-devel mailing list