Received-SPF: pass (google.com: domain of linux-kernel+bounces-34614-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 22 Jan 2024 20:55:39 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: George Guo <dongtai.guo@linux.dev>
Cc: Masami Hiramatsu <mhiramat@kernel.org>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Dennis Zhou <dennis@kernel.org>, Tejun
 Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>, Andrew Morton
 <akpm@linux-foundation.org>, George Guo <guodongtai@kylinos.cn>,
 linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
 linux-mm@kvack.org
Subject: Re: [PATCH] percpu: improve percpu_alloc_percpu_fail event trace
Message-ID: <20240122205539.705f5701@gandalf.local.home>
In-Reply-To: <20240123094443.00007b20@linux.dev>
References: <20240122073629.2594271-1-dongtai.guo@linux.dev>
	<20240122105700.05e5ee46@gandalf.local.home>
	<20240123094443.00007b20@linux.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 23 Jan 2024 09:44:43 +0800
George Guo <dongtai.guo@linux.dev> wrote:

> There are two reasons of percpu_alloc failed without warnings: 
> 
> 1. do_warn is false
> 2. do_warn is true and warn_limit is reached the limit.

Yes I know the reasons.

> 
> Showing do_warn and warn_limit makes things simple, maybe dont need
> kprobe again.

It's up to the maintainers of that code to decide if it's worth it or not,
but honestly, my opinion it is not.

The trace event in question is to trace that percpu_alloc failed and why.
It's not there to determine why it did not produce a printk message.

-- Steve