Re: [PATCH 1/3] softlockup: add sched_clock_tick() to avoid kernel warning on kgdb resume

[Dongdong Deng]

On Fri, Jan 29, 2010 at 10:51 PM, Jason Wessel
<jason.wessel@xxxxxxxxxxxxx> wrote:
> Ingo Molnar wrote:
>> * Jason Wessel <jason.wessel@xxxxxxxxxxxxx> wrote:
>>
>>
>>> @@ -118,6 +125,14 @@ void softlockup_tick(void)
>>> Â Â Â}
>>>
>>> Â Â Âif (touch_ts == 0) {
>>> + Â Â Â Â Â Âif (unlikely(per_cpu(softlock_touch_sync, this_cpu))) {
>>> + Â Â Â Â Â Â Â Â Â Â/*
>>> + Â Â Â Â Â Â Â Â Â Â * If the time stamp was touched atomically
>>> + Â Â Â Â Â Â Â Â Â Â * make sure the scheduler tick is up to date.
>>> + Â Â Â Â Â Â Â Â Â Â */
>>> + Â Â Â Â Â Â Â Â Â Âper_cpu(softlock_touch_sync, this_cpu) = false;
>>> + Â Â Â Â Â Â Â Â Â Âsched_clock_tick();
>>> + Â Â Â Â Â Â}
>>> Â Â Â Â Â Â Â__touch_softlockup_watchdog();
>>> Â Â Â Â Â Â Âreturn;
>>>
>>
>> Shouldnt just all of touch_softlockup_watchdog() gain this new
>> sched_clock_tick() call, instead of doing this ugly flaggery? Or would that
>> lock up or misbehave in other ways in some cases?
>>
>> That would also make the patch much simpler i guess, as we'd only have the
>> chunk above.
>>
>
> We have already been down that road, and it breaks other cases.
>
> http://lkml.org/lkml/2009/7/28/204
>
> Specifically the test case of:
>
> echo 3 > /proc/sys/kernel/softlockup_thresh
>
> And then some kernel code in a thread like:
> Â Â Â Âlocal_irq_disable();
> Â Â Â Âprintk("Disable local irq for 11 seconds\n");
> Â Â Â Âmdelay(11000);
> Â Â Â Âlocal_irq_enable();

Hi Jason,

Maybe this problem was fixed by
commit baf48f6577e581a9adb8fe849dc80e24b21d171d - "softlock: fix false
panic which can occur if softlockup_thresh is reduced".

Thanks,
Dongdong

>
>
> I could consider calling sched_cpu_clock() before returning the kernel
> to normal execution, but that didn't look very safe to call from the
> exception context, which is why it was delayed until the next time the
> soft lockup code ran.
>
> Resuming from a long sleep is a ugly problem, so I am open to short term
> and long term suggestions, including a polling time API (obviously we
> would prefer not to go down that rat hole :-)
>
> Jason.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
> Please read the FAQ at Âhttp://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/