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 09:30:19 +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 01:30:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A7133BE.4040905@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: AcoQ2R3eGHRWDUm4TSqusjrSJLvC2QAFtrib
Thread-topic: [Xen-devel] Cpu pools discussion
User-agent: Microsoft-Entourage/
On 30/07/2009 06:46, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>> Another alternative might be to create a 'hypervisor thread', either
>> dynamically, or a per-cpu worker thread, and do the work in that. Of course
>> that has its own complexities and these threads would also have their own
>> interactions with cpu pools to keep them pinned on the appropriate physical
>> cpu. I don't know whether this would really work out simpler.
> There should be an easy solution for this: What you are suggesting here sounds
> like a "hypervisor domain" similar to the the idle domain, but with high
> priority and normally all vcpus blocked.
> The interactions of this domain with cpupools would be the same as for the
> idle domain.
> I think this approach could be attractive, but the question is if the pros
> outweigh the cons. OTOH such a domain could open interesting opportunities.

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.

CPU hotplug raises a question in relation to cpupools, by the way. What pool
does a cpu get added to when it is brought online? And what do you do when
someone offlines a CPU (e.g., especially when it is the last in its pool)?
In that latter case, have you not considered it, or do you refuse the
offline, or do you somehow break the pool affinity so that domains belonging
to it can run elsewhere?

 -- Keir

Xen-devel mailing list