lkml.org 
[lkml]   [2014]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: frequent lockups in 3.18rc4

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [...]
>
> That's *especially* true if it turns out that the 3.17 problem
> you saw was actually a perf bug that has already been fixed and
> is in stable. We've been looking at kernel/smp.c changes, and
> looking for x86 IPI or APIC changes, and found some harmlessly
> (at least on x86) suspicious code and this exercise might be
> worth it for that reason, but what if it's really just a
> scheduler regression.
>
> There's been a *lot* more scheduler changes since 3.17 than the
> small things we've looked at for x86 entry or IPI handling. And
> the scheduler changes have been about things like overloaded
> scheduling groups etc, and I could easily imaging that some bug
> *there* ends up causing the watchdog process not to schedule.
>
> Hmm? Scheduler people?

Hm, that's a possibility, yes.

The watchdog threads are pretty simple beasts though, using
SCHED_FIFO:

kernel/watchdog.c: watchdog_set_prio(SCHED_FIFO, MAX_RT_PRIO - 1);

which is typically only affected by less than 10% of scheduler
changes - but it's entirely possible still.

It might make sense to disable the softlockup detector altogether
and just see whether trinity finishes/wedges, whether a login
over the console is still possible - etc.

The softlockup messages in themselves are only analytical, unless
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 is used.

Interesting bug.

Thanks,

Ingo


\
 
 \ /
  Last update: 2014-11-21 08:21    [W:0.470 / U:0.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site