From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C717D2550DD for ; Thu, 11 Dec 2025 20:34:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765485287; cv=none; b=AF32b4kg5rLOGBII4dF/rLL1uypdC6lAKsn81Fhm8+eGGHp5JdkyYDOMkwUIWglXJGj23hYFro8GXc4IsRZeufDNARc7d3ZxkBwgq3gcZwgOvFKVder8hslXzS/R7Mp/h5S6Z+nS8+PqpnhYlEWTxlyQQwhXuNgzSUYa54Jt5wI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765485287; c=relaxed/simple; bh=y9TYBiZodSL2wi6qGMZh34Plbtqk5JVMSFjyXyHQDKs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W8eC/cDn3KfKVV2fLq5pcfis6C6mNZYYY3B53JI4iahgLi0C0pkOlCUHpCvrsuPgUh2bIjhdB4UmWVDwXTCCQ/2CC6YWiDtbnb3chVLNstyeLvqdIF94MwybL/iA87yXMgWCfzDUzpto0lTqKrWnjr8vpUAmmaUKWH17KP1l05I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=RYmoBV/1; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="RYmoBV/1" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-477632d9326so3675935e9.1 for ; Thu, 11 Dec 2025 12:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1765485283; x=1766090083; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Sj4vHGFrdxNlGMAy6JePR4Eq8e6doCTvskR5SsEgWyY=; b=RYmoBV/1L1DqQL5x8ue2zXku+ye0C/LRI9cHlY9SUOeR+H3RokHGsWPuagT1bJ+MyA w7IN+OwygDVa9HBNhtU6z5WWRtOq7sFvWePp/7mRvRdJs3rMaGgcLlqOVdnnNKd4aMjQ FTp266EuXWMu9Ucr1EYmPYVmysAxx50HYyK1hI/SJJrSPcZNXU3C2BSYltXTQ1/tokzH PzFXpW6SjVj9ypry7F1w3lDa/N0XxfQQddQ0F/lLcfLur5ZmUJxsA64UiitB5qpkKnpJ YhWUV18RmJYXEYNuHU917qdSBF7eTGUhCiOkP2QdvFkpjkNDhELFSkdG4N20yyF1Htcu h60w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765485283; x=1766090083; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Sj4vHGFrdxNlGMAy6JePR4Eq8e6doCTvskR5SsEgWyY=; b=JyZAvmZ3u+tY5sMq8KKz9H+sG9MXUSIYM/EHPSwGzJwgw1dD0drLYHPi1K/XuzXj+d pMAShACk/iv/2EU7pDrd7tf37IOcqbLrqp/ays02dG8ZSAcy+srbcK+4MW4uDE7RUJvG hnadybz9rdJ5dFqGBTfkoQXmnG0qfmHSJrt9LpuE3AF7/hpMiTeFzndAJS1jmyYVKJUs SEAT6zzwpLQGYahYDgyIg2UUuPaW/qqygmTIol2AgK2NM1E9itVCSCu5QBrXKnyVrmoR Ujoe55j91dmoUUUIWCAdnn6ZP2lahy69IcnMc7fPOmdaGGCfFnzTRO+pXcIrHsNYvDFm xUWQ== X-Forwarded-Encrypted: i=1; AJvYcCUwlV21qKr8PQCJTDs/Mk/bI1uIduJJCsS/095sPdoJ0LzXSrrVintbwRvTqYYA9p1puT2MoBL2/67rgCU=@vger.kernel.org X-Gm-Message-State: AOJu0Yzmss7rfD23KXPv+BdaOngcYu7mxMU2Z2QVSdQmMyqZAaed5MLf uKJl8YK/DgLuXRUdHjXU0ZNSB0Ruv3JhM5WF/bxd9tr0eByrXioN1Qd+HJoO32jnEINHizZqQkA qTEhI X-Gm-Gg: AY/fxX7zjeXApj8X8QZAi5icfL7op+JKCsgc+baXb9Y5UxeTguek2YjLD/qa2lyg2TD ewnJ21G+eFrE7zzuHSkVyW2g2dFqE6f+Do+Q4vNz3kgoT6EWNPcPXR1Q8GVP1xUjujUK1xa1ers 3foCnKgnemjFiiLGIb+8TJkV86T1/5lvrkPu12/m2ozP59qh4ZP4sSsi6R+deyx38JeEfF6EIcn 1KTo4HfTpGvxHXv2EIIsXUt1d+344U/0n6yRmGstEUCII9sKMJZ74hv0OCBq+BulRyLofZ19OQT XvrTsWsm10Z4e1h/Z/mHhrjX8y4+0NsmT6N42UAzK2l6ebq/qbky4ih3O4WUhw+iuzkcsNH+ejm LKKEUhq0IOn/oUn+icWPzc85LosQ8/ND25JhWx9BmlwFyY9iuTPkPEVm5Goq9smSMlBUgnDRZ+Q RVM/JNj1rdXxZ4h1yLg4fPnA== X-Google-Smtp-Source: AGHT+IGyx2iUEQnz32pJ0VXihoWHyouksjWFx6kE0ID4txQnGC+oPIJuwT05P62l3LSn8EVKRr02yw== X-Received: by 2002:a05:600c:5286:b0:477:5af7:6fa with SMTP id 5b1f17b1804b1-47a838586abmr68725905e9.32.1765485283077; Thu, 11 Dec 2025 12:34:43 -0800 (PST) Received: from localhost (109-81-21-76.rct.o2.cz. [109.81.21.76]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a89f1e947sm61877585e9.3.2025.12.11.12.34.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Dec 2025 12:34:42 -0800 (PST) Date: Thu, 11 Dec 2025 21:34:41 +0100 From: Michal Hocko To: Yang Xin Cc: akpm@linux-foundation.org, rientjes@google.com, shakeel.butt@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Xin Subject: Re: [PATCH] mm/oom_kill: add sysctl_oom_dump_stack to control kernel stack dumping on OOM Message-ID: References: <20251211202433.4495-1-redleaf@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251211202433.4495-1-redleaf@linux.alibaba.com> 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. > Signed-off-by: Yang Xin > --- > mm/oom_kill.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5eb11fbba704..a51dbd2e6912 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -56,6 +56,7 @@ > static int sysctl_panic_on_oom; > static int sysctl_oom_kill_allocating_task; > static int sysctl_oom_dump_tasks = 1; > +static int sysctl_oom_dump_stack = 1; > > /* > * Serializes oom killer invocations (out_of_memory()) from all contexts to > @@ -464,7 +465,9 @@ static void dump_header(struct oom_control *oc) > if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order) > pr_warn("COMPACTION is disabled!!!\n"); > > - dump_stack(); > + if (sysctl_oom_dump_stack) > + dump_stack(); > + > if (is_memcg_oom(oc)) > mem_cgroup_print_oom_meminfo(oc->memcg); > else { > @@ -736,6 +739,13 @@ static const struct ctl_table vm_oom_kill_table[] = { > .mode = 0644, > .proc_handler = proc_dointvec, > }, > + { > + .procname = "oom_dump_stack", > + .data = &sysctl_oom_dump_stack, > + .maxlen = sizeof(sysctl_oom_dump_stack), > + .mode = 0644, > + .proc_handler = proc_dointvec, > + }, > }; > #endif > > -- > 2.30.2 > -- Michal Hocko SUSE Labs