Re: [PATCH] mm/oom_kill: add sysctl_oom_dump_stack to control kernel stack dumping on OOM

[David Rientjes <rientjes@google.com>]

On Thu, 11 Dec 2025, Michal Hocko wrote:

> On Fri 12-12-25 04:24:33, Yang Xin wrote:
> >     Most OOM kills triggered by user-space processes produce kernel stack
> >     traces that are not helpful for diagnosing the root cause. These traces
> >     usually just show the page fault handler or system call entry.
> > 
> >     Furthermore, dump_stack() can be expensive. It often runs with
> >     interrupts disabled or holds the console lock for a long time,
> >     potentially causing system latencies and preventing the system from
> >     responding to other events.
> > 
> >     This patch adds a new sysctl vm.oom_dump_stack to control this
> >     behavior. Writing '0' to /proc/sys/vm/oom_dump_stack suppresses the
> >     kernel stack dump during OOM kills, while '1' (the default) preserves
> >     the existing behavior.
> 
> While I fundamentally do not object to ways to suppress stacks traces
> for OOM I would really like to hear more what kind of overhead we are
> talking about here (stack traces are reported for tracing and other low
> latency situations) and why does this matter for as cold of a path as
> OOM is.
> 
> Also we are getting way too many of these sysctls. Maybe it is time to
> look for a more customizable way to configure oom output that doesn't
> require sysctl per output feature.
> 

Strongly agree, I don't think this requires yet another sysctl.  It's also 
global, so it will affect all oom kills including the ones where you might 
find a stack to actually be really helpful to understand the issue.