Dietmar Hahn
2011-Mar-15 09:00 UTC
[Xen-devel] Question to [PATCH 2 of 3] PoD: Allow pod_set_cache_target hypercall to be preempted
Hi, we stumbled over this problem fixed in http://lists.xensource.com/archives/html/xen-devel/2011-01/msg01155.html on SLES11 SP1 with domU''s with memory >= 64GB. The effect was that dom0 seemed to hang even though our dom0 were running on 3 cpus. Now my question: I had a look at hypercall_create_continuation() and my understanding is that the caller on this cpu is prepared to start the hypercall again after getting scheduled next time and the hypercall is finished immediately to deliver irqs and events. But what about the other cpus in dom0? Are these waiting for an irq/event from the cpu handling the long running hypercall? How do these benefit from this hypercall continuation? Thanks! Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Mar-15 09:40 UTC
Re: [Xen-devel] Question to [PATCH 2 of 3] PoD: Allow pod_set_cache_target hypercall to be preempted
>>> On 15.03.11 at 10:00, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > I had a look at hypercall_create_continuation() and my understanding is that > the caller on this cpu is prepared to start the hypercall again after > getting scheduled next time and the hypercall is finished immediately to > deliver irqs and events. > But what about the other cpus in dom0? Are these waiting for an irq/event > from the cpu handling the long running hypercall? > How do these benefit from this hypercall continuation?One vCPU stuck in a long running hypercall can, depending on what locks/mutexes/semaphores it holds, keep other vCPU-s in the same domain from making progress. Whether that''s what happens in your case can only be determined by looking at what those other vCPU-s were doing (or trying to do) at the time of the hang (from SysRq-t or ''0'' [or ''d''] debug key output). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dietmar Hahn
2011-Mar-15 12:01 UTC
Re: [Xen-devel] Question to [PATCH 2 of 3] PoD: Allow pod_set_cache_target hypercall to be preempted
Am 15.03.2011 schrieb "Jan Beulich <JBeulich@novell.com>":> >>> On 15.03.11 at 10:00, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > I had a look at hypercall_create_continuation() and my understanding is that > > the caller on this cpu is prepared to start the hypercall again after > > getting scheduled next time and the hypercall is finished immediately to > > deliver irqs and events. > > But what about the other cpus in dom0? Are these waiting for an irq/event > > from the cpu handling the long running hypercall? > > How do these benefit from this hypercall continuation? > > One vCPU stuck in a long running hypercall can, depending on what > locks/mutexes/semaphores it holds, keep other vCPU-s in the same > domain from making progress. Whether that''s what happens in > your case can only be determined by looking at what those other > vCPU-s were doing (or trying to do) at the time of the hang (from > SysRq-t or ''0'' [or ''d''] debug key output). > > Jan >OK, thanks! Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel