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: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vc

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 02 Feb 2007 02:06:38 +0000
Delivery-date: Thu, 01 Feb 2007 18:06:21 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1E846CA.8BD7%Keir.Fraser@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdESFqDCWsISfq5RGeHgxcxVzRqmQACelaDAAAZiDAAAP4q2wADxf1QAAFVV3AAAMUYXAAACCkwAACFZyAAAV9OMAABEoucACBxTEAATS41lQANfeFwAACGefIAAJFJTQAA88jJ
Thread-topic: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix softlockup issue after vcpu hotplug
User-agent: Microsoft-Entourage/11.2.5.060620
On 2/2/07 01:39, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> Odder still, the softlockup threads are SCHED_FIFO/99 in 2.6.16 too. So the
> main change is that rather than an explicit sleep of one second, the thread
> now sleeps as TASK_INTERRUPTIBLE. I wonder how it gets kicked back to
> TASK_RUNNING?
> 
> http://lwn.net/Articles/173648/ is worrying since it seems to state that the
> patch intends to make the thread timer-interrupt driven rather than softirq
> timer driven. If that means it is jiffy-ticker driver, then perhaps the
> softlockup module is incompatible with tickless idle mode (no-idle-hz).

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.

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



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