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: Wed, 29 Jul 2009 14:00:20 +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: Wed, 29 Jul 2009 06:03:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A70418A.5000302@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: AcoQSL8atJB6QEWYQn6ud1XR0oekNgAA8fIm
Thread-topic: [Xen-devel] Cpu pools discussion
User-agent: Microsoft-Entourage/
On 29/07/2009 13:33, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:

>>> Would you feel better if I'd try to eliminate the reason for cpupool_borrow?
>>> This function is needed only for continue_hypercall_on_cpu outside of the
>>> current pool. I think it should be possible to replace those by
>>> on_selected_cpus with less impact on the whole system.
>> Some of the stuff in the continuation handlers cannot be executed in irq
>> context. 'Fixing' that would make many of the users ugly and less
>> maintainable, so getting borrow/return right is the better answer I think.
> The alternative would be a tasklet set up in irq.
> And we are speaking of 3 users.
> I could try a patch and then we could compare the two solutions. What do you
> think?

This would work for a couple of callers, but some really need to be running
in dom0 context. Or, more precisely, not the context of some other domain
(softirqs synchronously preempt execution of a vcpu context). This can lead
to subtle deadlocks, for example in freeze_domains() and in __cpu_die(),
because we may need the vcpu we have snchronously preempted to make some
progress for ourselves to be able to get past a spin loop.

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.


Xen-devel mailing list