On Fri 15-09-17 21:09:29, Tetsuo Handa wrote:

Michal Hocko wrote:

quoted

On Fri 15-09-17 20:38:49, Tetsuo Handa wrote:
[...]

quoted

You said "identify _why_ we see the lockup trigerring in the first
place" without providing means to identify it. Unless you provide
means to identify it (in a form which can be immediately and easily
backported to 4.9 kernels; that is, backporting not-yet-accepted
printk() offloading patchset is not a choice), this patch cannot be
refused.

I fail to see why. It simply workarounds an existing problem elsewhere
in the kernel without deeper understanding on where the problem is. You
can add your own instrumentation to debug and describe the problem. This
is no different to any other kernel bugs...

Please do show us your patch for that. Normal users cannot afford developing
such instrumentation to debug and describe the problem.

Stop this nonsense already! Any kernel bug/lockup needs a debugging
which might be non-trivial and it is necessary to understand the real
culprit. We do not add random hacks to silence a problem. We aim at
fixing it!
 

quoted

If our printk implementation is so weak it cannot cope with writers then
that should be fixed without spreading hacks in different subsystems. If
the lockup is a real problem under normal workloads (rather than
artificial ones) then we should try to throttle more aggresively.

No throttle please. Throttling makes warn_alloc() more and more useless.

so does try_lock approach...

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>