Re: [Xen-devel] Cpu pools discussion

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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.

 Thanks,
 Keir



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