[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240123094443.00007b20@linux.dev>
Date: Tue, 23 Jan 2024 09:44:43 +0800
From: George Guo <dongtai.guo@...ux.dev>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Dennis Zhou <dennis@...nel.org>, Tejun
Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>, Andrew Morton
<akpm@...ux-foundation.org>, George Guo <guodongtai@...inos.cn>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH] percpu: improve percpu_alloc_percpu_fail event trace
On Mon, 22 Jan 2024 10:57:00 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 22 Jan 2024 15:36:29 +0800
> George Guo <dongtai.guo@...ux.dev> wrote:
>
> > From: George Guo <guodongtai@...inos.cn>
> >
> > Add do_warn, warn_limit fields to the output of the
> > percpu_alloc_percpu_fail ftrace event.
> >
> > This is required to percpu_alloc failed with no warning showing.
>
> You mean to state;
>
> In order to know why percpu_alloc failed but produces no warnings,
> the do_warn and warn_limit should be traced to let the user know it
> was rate-limited.
>
> Or something like that?
>
> Honestly, I don't think that the trace event is the proper place to do
> that. The trace event just shows that it did fail. If you are
> confused to why it doesn't print to dmesg, then you can simply add a
> kprobe to see those values as well.
>
> -- Steve
>
> >
> > Signed-off-by: George Guo <guodongtai@...inos.cn>
> > ---
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.
Showing do_warn and warn_limit makes things simple, maybe dont need
kprobe again.
Powered by blists - more mailing lists