Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.12 at 08:59, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 04/09/2012 07:35, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@xxxxxxxxxxxxxx> wrote:
>>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " 
>>>> lines,
>>>> mean while on the normal console, S-ATA devices are starting to give 
>>>> errors.
>>> 
>>> In this case the handler must be running in tasklet context. Not sure why
>>> SATA interrupts would be affected as hardirq and softirq work will still be
>>> carried out during execution of the keyhandler (the handler voluntarily
>>> preempts itself for softirq work).
>>> 
>>> Would need more investigation. :)
>> 
>> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
>> get preferred in the schedulers? Some compensation might be
>> needed for the penalized vCPU, at least if that one is pinned
>> (not sure whether load balancing would be able to steal the
>> head of the run queue from a remote CPU). Sander - are you
>> by chance pinning Dom0 vCPU-s? And how many of them does
>> your Dom0 have?
> 
> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
> going to expend too much brain power on this situation. The case of spending
> a few minutes in one key handler is not one I think is particularly sane.

Which imo would call for reverting the patch. But then again, other
key handlers can easily take pretty long too (particularly on large
systems, albeit it is clear that the one here is particularly bad), and
declaring all of them pretty much useless probably isn't the best
choice (as then we could as well rip them all out).

Bottom line - _I_ think we should try to do something about this.
An apparent option would be to have low priority tasklets (for
just this purpose, as all others we certainly want to take priority),
if that can reasonably be integrated with the schedulers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel