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

["Yu, Ke" <ke.yu@xxxxxxxxx>]

Hi Jan,

The attached is the updated patch per your suggestion. generally this patch use 
the per-CPU urgent vCPU count to indicate if cpu should enter deep C state. it 
introduce per-VCPU urgent flag, and update the urgent VCPU count when vCPU 
state is changed. Could you please take a look. Thanks 

Regards
Ke

>-----Original Message-----
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Monday, February 08, 2010 5:08 PM
>To: Yu, Ke
>Cc: Keir Fraser; Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] cpuidle causing Dom0 soft lockups
>
>>>> "Yu, Ke" <ke.yu@xxxxxxxxx> 07.02.10 16:36 >>>
>>The attached is the updated patch, it has two changes
>>- change the logic from local irq disabled *and* poll event to local irq
>disabled *or* poll event
>
>Thanks.
>
>>- Use per-CPU vcpu list to iterate the VCPU, which is more scalable. The
>original scheduler does not provide such kind of list, so this patch implement
>the list in scheduler code.
>
>I'm still not really happy with that solution. I'd rather say that e.g.
>vcpu_sleep_nosync() should set a flag in the vcpu structure indicating
>whether that one is "urgent", and the scheduler should just maintain
>a counter of "urgent" vCPU-s per pCPU. Setting the flag when a vCPU
>is put to sleep guarantees that it won't be mis-treated if it got woken
>by the time acpi_processor_idle() looks at it (or at least the window
>would be minimal - not sure if it can be eliminated completely). Plus
>not having to traverse a list is certainly better for scalability, not the
>least since you're traversing a list (necessarily) including sleeping
>vCPU-s (i.e. the ones that shouldn't affect the performance/
>responsiveness of the system).
>
>But in the end it would certainly depend much more on Keir's view on
>it than on mine...
>
>Jan

Attachment: cpuidle-hint-count-v2.patch
Description: cpuidle-hint-count-v2.patch

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