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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> "Yu, Ke" <ke.yu@xxxxxxxxx> 16.02.10 14:12 >>>
>>Two remarks: For one, your patch doesn't consider vCPU-s with event
>>delivery disabled urgent anymore. 
>
>Oh, sorry that I made this change without telling the reason. When vCPU is 
>blocked with event delivery disabled, it is either guest CPU offline or guest 
>CPU polling on event channel. Offlined guest CPU should not be treated as 
>urgent vCPU, so we only need to track the event channel polling case. this is 
>the reason why I simplify the logic to only treat vCPU polling on event 
>channel as urgent vCPU.

Ah, yes, that makes sense. But it also makes me think about the concept of the 
change as a whole again: A vCPU polling for an event doesn't really indicate 
whether it is urgent. It just so happens that polling can be used from the spin 
lock path. There could be other uses of polling that would not warrant keeping 
the underlying pCPU from entering deep C states. Perhaps this should rather be 
based on a guest hint (passed either with the poll hypercall or associated 
permanently with an event channel) then?

>>I would think we should either avoid the atomic ops altogether if
>>old_cpu == new_cpu, or switch the updating order (inc before dec).
>
>Do you mean when old_cpu == new_cpu, and if urgent_count == 1, current 
>approach (dec before inc) has small time window (after dec, before inc) that 
>urgent_count==0, thus may mislead couidle driver. if this is the case, I am 
>fine with it and prefer to switching the updating order.

Yes, that was my point.

Jan


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