[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 10:48:31 +0800
  • Delivery-date: Thu, 01 Feb 2007 18:48:21 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdESFqDCWsISfq5RGeHgxcxVzRqmQACelaDAAAZiDAAAP4q2wADxf1QAAFVV3AAAMUYXAAACCkwAACFZyAAAV9OMAABEoucACBxTEAATS41lQANfeFwAACGefIAAJFJTQAA88jJAAFt7gA=
  • 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日 10:07
>
>Okay, I now see how this works -- the thread is kicked from
>softlockup_tick(), from the timer ISR. So this wakeup event is hidden
>from
>next_timer_interrupt(), which only searches timer wheels and hrtimers.

Exactly.

>
>The strictly correct fix here is to make next_timer_interrupt()
>softlockup-aware. I would say it is currently incorrect in the presence of
>softlockup since it is not doing its job (telling an idle process what the
>next time-based event is that it must wake up for).
>
>We can do this by adding a softlockup_get_next_event(), called from the
>bottom of next_timer_interrupt(). I would pass it the current return value
>and have it return an adjusted value: so in the absence of softlockup it
>would simply return its argument unmodified. In the presence of
>softlockup
>it would return a sooner value if softlockup is the next event to fire.
>
>Do you want to try coding this up?
>
> -- Keir

Sure.

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