Messages in this thread | | | Date | Sat, 13 Dec 2014 08:43:32 +0100 | From | Ingo Molnar <> | Subject | Re: frequent lockups in 3.18rc4 |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, Dec 12, 2014 at 11:58 AM, David Lang <david@lang.hm> wrote: > > > > If the machine has NOHZ and has a cpu bound userspace task, > > it could take quite a while before userspace would trigger a > > reschedule (at least if I've understood the comments on this > > thread properly) > > The thing is, we'd have to return to user space for that to > happen. And when we do that, we check the "should we schedule" > flag again. So races like this really shouldn't matter, but > there could be something kind-of-similar that just ends up > causing a wakeup to be delayed.
Furthermore there ought to be a scheduler tick active in that case - which won't be as fast as an immediate reschedule, but fast enough to beat the softlockup watchdog's threshold of 20 seconds or so.
That is why I think it would be interesting to examine how the locked up state looks like: is the system truly locked up, impossible to log in to, locks held but not released, etc., or is the lockup transient?
> But it would need to be delayed for seconds (for the RCU > threads) or for tens of seconds (for the watchdog) to matter. > > Which just seems unlikely. Even the "very high load" thing > shouldn't really matter, since while that could delay one > particular thread being scheduled, it shouldn't delay the next > "should we schedule" test. In fact, high load would normally be > extected to make the next "should we schedule" come faster. > > But this is where some load calculation overflow might screw > things up, of course.
Also, the percpu watchdog threads are SCHED_FIFO:99, woken up through percpu hrtimers, which are not easy to delay through high SCHED_OTHER load.
Thanks,
Ingo
| |