Re: [Xen-devel] POD: soft lockups in dom0 kernel

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.12.13 at 12:07, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> We do not want to disable the soft lockup detection here as it has found
> a bug.  We can't have tasks that are unschedulable for minutes as it
> would only take a handful of such tasks to hose the system.

My understanding is that the soft lockup detection is what its name
says - a mechanism to find cases where the kernel software locked
up. Yet that's not the case with long running hypercalls.

> We should put an explicit preemption point in.  This will fix it for the
> CONFIG_PREEMPT_VOLUNTARY case which I think is the most common
> configuration.  Or perhaps this should even be a cond_reched() call to
> fix it for fully non-preemptible as well.

How do you imagine to do this? When the hypervisor preempts a
hypercall, all the kernel gets to see is that it drops back into the
hypercall page, such that the next thing to happen would be
re-execution of the hypercall. You can't call anything at that point,
all that can get run here are interrupts (i.e. event upcalls). Or do
you suggest to call cond_resched() from within
__xen_evtchn_do_upcall()?

And even if you do - how certain is it that what gets its continuation
deferred won't interfere with other things the kernel wants to do
(since if you'd be doing it that way, you'd cover all hypercalls at
once, not just those coming through privcmd, and hence you could
end up with partially completed multicalls or other forms of batching,
plus you'd need to deal with possibly active lazy modes).

Jan


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