* Linus Torvalds <torva...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
