WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Subject: RE: [Xen-devel] cpuidle causing Dom0 soft lockups
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 5 Feb 2010 17:52:42 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 05 Feb 2010 01:54:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B6BEF70020000780002DE0F@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B58402E020000780002B3FE@xxxxxxxxxxxxxxxxxx> <C77DE51B.6F89%keir.fraser@xxxxxxxxxxxxx> <4B67E85E020000780002D1A0@xxxxxxxxxxxxxxxxxx> <8B81FACE836F9248894A7844CC0BA814250B940CFF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B6BE984020000780002DDF9@xxxxxxxxxxxxxxxxxx> <73BDC2BA3DA0BD47BAAEE12383D407EF35C82CF4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B6BEF70020000780002DE0F@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqmQ4C0JoKwkfX1TRuJXAcarrd9hgABBpqg
Thread-topic: [Xen-devel] cpuidle causing Dom0 soft lockups
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>Sent: 2010年2月5日 17:14
>
>>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 05.02.10 10:00 >>>
>>>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>>>Sent: 2010年2月5日 16:49
>>>
>>>Yes, this patch works for us too. So a non-hacky version of 
>it would be
>>>appreciated.
>>>
>>>I also meanwhile tried out the idea to reduce the contention on
>>>xtime_lock (attached for reference). Things appear to work fine, but
>>>there is an obvious problem (with - thus far to me - no obvious
>>>explanation) with it: The number of timer interrupts on CPUs not on
>>>duty to run do_timer() and alike is increasing significantly, 
>>>with spikes
>>>of over 100,000 per second. I'm investigating this, but of course any
>>>idea anyone of you might have what could be causing this would be
>>>very welcome.
>>>
>>
>>forgive my poor english. From your patch, only cpu on duty will invoke
>>do_timer to update global timestamp. Why in your test it's CPUs 'not
>>on duty' to have high frequent do_timer? I may read it wrong. :-(
>
>If you look at the patch, I added extra statistics for those timer
>interrupts that occur when a CPU is "on duty" (recorded as IRQ0,
>which is otherwise unused) and when not "on duty" (recorded as MCEs,
>since those hopefully(!!!) won't occur either, and in no case at a high
>rate).
>
>From that I know that the rate of interrupts (not the rate of 
>do_timer()
>invocations) is much higher on not-on-duty CPUs, but is roughly as
>without the patch for the on-duty one.
>

Are 100,000 per second a sum-up on all non-duty CPUs or observed on
just one? How about the level without the patch?

Your patch is quite straightforward, and in a glimpse it shouldn't have
such weird issue... Timer interrupts are caused in two paths: one is 
periodic timer when vcpu is running. As you have HZ=250, you won't 
get >250 interrupts in this portion as Xen accurately drives injections 
in 4ms pace. The other is singleshot timer when vcpu is entering idle. 
periodic timer will be stopped in that case, and a singleshot timer is 
registered with nearest expiration in local timer queue. That portion is
unpredictable, then possibly your patch increases hotness in that part.
But I haven't figured out how it could be. :-(

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