[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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 01 Feb 2007 18:41:46 +0000
  • Delivery-date: Thu, 01 Feb 2007 10:41:27 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdESFqDCWsISfq5RGeHgxcxVzRqmQACelaDAAAZiDAAAP4q2wADxf1QAAFVV3AAAMUYXAAACCkwAACFZyAAAV9OMAABEoucACBxTEAATS41lQ==
  • Thread-topic: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug

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 --
it's certainly concerning that clamping the time we block for makes a
difference. It would seem to imply that we are missing work to do sometimes
when we block (e.g., perhaps they are on a timer wheel that we do not check,
or there is some outstanding rcu work that we do not check for, or something
like that). It feels like maybe something about the way that deferred work
is managed has changed a bit in core Linux and the Xen parts haven't caught
up. :-)

 -- Keir



_______________________________________________
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®.