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

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: Tue, 30 Jan 2007 09:37:32 +0000
  • Delivery-date: Tue, 30 Jan 2007 01:42:05 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdESFqDCWsISfq5RGeHgxcxVzRqmQACelaD
  • Thread-topic: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug

On 30/1/07 08:26, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Stamp softlockup thread earlier before do_timer, because the
> latter is the one to actually trigger lock warning for
> long-time offline. Or else, I obserevd softlockup warning
> easily at manual vcpu hot-remove/plug, or when suspend cancel
> into old context.

Actually the softlockup check is triggered from run_local_timers() which is
called very near the end of timer_interrupt(). So the existing location for
stamping the softlockup thread should be fine.

> One point here is to cover both stolen and blocked time to
> compare with offline threshold. vcpu hotplug falls into 'stolen'
> case, but it's not enough. Considering xen time model is tickless
> at idle, it's possible that big block time is requested which
> also inflames softlockup thread.

Every vcpu has a softlockup thread which regularly sleeps for some short
period. If the vcpu sets a timeout beyond that sleep time then we have a
bug. We shouldn't need to take into account blocked time -- Xen already
ensures that wakeup latency is accounted as stolen time. Blocked time only
includes time which the vcpu was willing to give up because it had no work
to do.

 -- Keir

Xen-devel mailing list



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