Messages in this thread | | | Date | Thu, 15 Mar 2012 13:42:29 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] watchdog: Make sure the watchdog thread gets CPU on loaded system |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2012-03-15 at 12:00 +0100, Peter Zijlstra wrote: > > On Wed, 2012-03-14 at 18:45 -0700, Mandeep Singh Baines wrote: > > > You could make MAX_RT_PRIO greater than MAX_USER_RT_PRIO but that > > > might > > > have some impact on real-time applications. A simple one-line patch: > > > > > > - #define MAX_RT_PRIO MAX_USER_RT_PRIO > > > + #define MAX_RT_PRIO (MAX_USER_RT_PRIO + 1) > > > > > > would prevent user-space from causing a false lockup detection. > > > > We're so not going to muck with the fifo priorities just for this stupid > > soft watchdog,.. I already hate that I can't disable the piece of crap, > > making it more involved is just really not going to happen. > > And before people start to whinge about that, all the soft > watchdog issues I've seen fly by the past year or so all were > bugs in the watchdog itself, I can't actually remember it > flagging a real problem.
Its efficiency always depended on which area I was working on. For syscall level stuff it helped me numerous times.
> The NMI watchdog otoh works like a charm for me and regularly > helps out when I done stupid.
Sure, you are mostly working on perf events, the scheduler and related core kernel areas so when you are stupid you get a hard lockup or worse, quickly. Not much room for soft lockups.
So it's more of a case of selection bias, me thinks.
So unless there's concensus to remove everything but the hard lockup detection facilities, lets solve the technical problem at hand, ok?
Thanks,
Ingo
| |