Mailing List Archive

RE: [PATCH][RESEND]RE: [PATCH] Fix softlockup issue aftervcpu hotplug
Hi, Keir,
Please check whether attached patch matches
your suggestion. Test OK with vcpu hotplug and save/restore.

Thanks,
Kevin

>From: Tian, Kevin
>Sent: 2007Äê2ÔÂ2ÈÕ 10:49
>>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
RE: [PATCH][RESEND]RE: [PATCH] Fix softlockup issue aftervcpu hotplug [ In reply to ]
Keir, how about your opinion about this version? Maybe I missed
your reply...

Thanks,
Kevin

>-----Original Message-----
>From: Tian, Kevin
>Sent: 2007Äê2ÔÂ2ÈÕ 21:57
>To: Tian, Kevin; Keir Fraser; xen-devel@lists.xensource.com
>Subject: RE: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix
>softlockup issue aftervcpu hotplug
>
>Hi, Keir,
> Please check whether attached patch matches
>your suggestion. Test OK with vcpu hotplug and save/restore.
>
>Thanks,
>Kevin
>
>>From: Tian, Kevin
>>Sent: 2007Äê2ÔÂ2ÈÕ 10:49
>>>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@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH][RESEND]RE: [PATCH] Fix softlockup issue aftervcpu hotplug [ In reply to ]
I'm travelling so I'm not getting through the patch queue as quickly as
usual. The patch looks fine -- it may get checked in today.

-- Keir

On 4/2/07 12:30, "Tian, Kevin" <kevin.tian@intel.com> wrote:

> Keir, how about your opinion about this version? Maybe I missed
> your reply...
>
> Thanks,
> Kevin
>
>> -----Original Message-----
>> From: Tian, Kevin
>> Sent: 2007$BG/(B2$B7n(B2$BF|(B 21:57
>> To: Tian, Kevin; Keir Fraser; xen-devel@lists.xensource.com
>> Subject: RE: [PATCH][RESEND]RE: [Xen-devel] [PATCH] Fix
>> softlockup issue aftervcpu hotplug
>>
>> Hi, Keir,
>> Please check whether attached patch matches
>> your suggestion. Test OK with vcpu hotplug and save/restore.
>>
>> Thanks,
>> Kevin
>>
>>> From: Tian, Kevin
>>> Sent: 2007$BG/(B2$B7n(B2$BF|(B 10:49
>>>> 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@lists.xensource.com
http://lists.xensource.com/xen-devel