RE: [Xen-devel] cpuidle causing Dom0 soft lockups

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>Sent: 2010年2月5日 22:59
>
>>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 05.02.10 12:16 >>>
>>Possible options is to take jiffies, system timestamp, and per-cpu
>>timestamp in stop_hz_timer, to generate a local latest value. Or
>>a per-cpu jiffies can be generated in per-cpu timer interrupt, which
>>is only used in per-cpu style like in stop_hz_timer.
>
>That was my next thought too - but it doesn't work (unless I made a
>blatant mistake). Not only does it not get the interrupt rate down,
>it even grows it on the duty CPU, and it creates visible brief hangs
>as well a rushes of time.

This really twists my head. Ideally with above option singleshot timer
is postponed and there's really no point to instead kick interrupt rate
up... Possibly you can add some trace in Xen side to check singleshot
timer registration/exipiration pattern. At least this is only suspicious
virtual timer pending path from my perspective, which is worthy of
some checking to understand what's going wrong from another angle.

>
>Next I'll do is try to detect when the duty CPU is de-scheduled, and
>move on the duty to one that is scheduled (i.e. one that is currently
>executing timer_interrupt()).
>

It's still possible that you move duty to one active CPU, while that
active CPU is in stop_hz_timer with interrupt disabled. In that case,
again no one is able to update jiffies and again stale jiffies can be
observed... 

Thanks,
Kevin

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