[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 2 Feb 2007 09:10:42 +0800
  • Delivery-date: Thu, 01 Feb 2007 17:10:26 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdESFqDCWsISfq5RGeHgxcxVzRqmQACelaDAAAZiDAAAP4q2wADxf1QAAFVV3AAAMUYXAAACCkwAACFZyAAAV9OMAABEoucACBxTEAATS41lQANfeFw
  • Thread-topic: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年2月2日 2:42
>On 31/1/07 06:17, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> So in 2.6.16, watchdog thread itself promises max timeout
>> to about 1s by hooking a timer, while In 2.6.18, the max timeout
>> value is volatile
>
>But the softlockup thread implementation has not changed between
>2.6.16 and
>2.6.18. The periodic delay is caused by the thread itself calling
>msleep_interruptible(1000) which should, as part of its implementation,
>queue up a timer. So this erratic behaviour on 2.6.18 is still worrying --

So, am I looking at wrong code? In 2.6.16:
        while (!kthread_should_stop()) {
                msleep_interruptible(1000);
                touch_softlockup_watchdog();
        }

While in 2.6.18:
        while (!kthread_should_stop()) {
                set_current_state(TASK_INTERRUPTIBLE);
                touch_softlockup_watchdog();
                schedule();
        }

I don't think same logic kept there. :-)

Thanks,
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.