Messages in this thread | | | Date | Fri, 21 Nov 2014 07:37:42 +0100 | From | Ingo Molnar <> | Subject | Re: 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
| |