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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

I'm going to do a -rc3 today I think. Shall I roll this one in?

 -- Keir

On 13/02/2010 02:28, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:

> 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
> 



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