From: Steven Rostedt <rostedt@goodmis.org>
To: Liao Chang <liaochang1@huawei.com>
Cc: <mhiramat@kernel.org>, <mark.rutland@arm.com>,
<mathieu.desnoyers@efficios.com>,
<linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] function_graph: Improve fgraph LRU data initialization
Date: Mon, 30 Sep 2024 10:55:50 -0400 [thread overview]
Message-ID: <20240930105550.564d5a67@gandalf.local.home> (raw)
In-Reply-To: <20240930071031.3694979-1-liaochang1@huawei.com>
On Mon, 30 Sep 2024 07:10:31 +0000
Liao Chang <liaochang1@huawei.com> wrote:
> This patch uses [first ... last] = value to initialize fgraph_array[].
> And use fgraph_lru_next and fgraph_lru_last as the indicator of
> initialization.
The only thing this patch does is to allow the use of [first...last]
annotation for initialization. What actual benefit does that give us?
In other words, why would I want to apply this? Just so that we can use
[first...last] annotation with the added cost of having to manage setting
fgraph_lru_next and fgraph_lru_last to -1 and then comparing them?
Personally, I find the original code easier to maintain, as it's simple and
doesn't add extra management.
-- Steve
>
> v2->v1:
> Fixup the build error reported by kernel test robot <lkp@intel.com>.
> Since some architectures use ftrace_graph_entry_stub() for the static
> ftrace scenario, then restore the definition without static keyword in
> the original patch [1]. And rebasing patch to next-20240927.
>
> [1] https://lore.kernel.org/all/20240912111550.1752115-1-liaochang1@huawei.com
>
> Signed-off-by: Liao Chang <liaochang1@huawei.com>
> ---
> kernel/trace/fgraph.c | 54 +++++++++++++++++++++----------------------
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index d7d4fb403f6f..eb2fbc0338c7 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -172,20 +172,41 @@ enum {
> DEFINE_STATIC_KEY_FALSE(kill_ftrace_graph);
> int ftrace_graph_active;
>
> -static struct fgraph_ops *fgraph_array[FGRAPH_ARRAY_SIZE];
> +int ftrace_graph_entry_stub(struct ftrace_graph_ent *trace,
> + struct fgraph_ops *gops)
> +{
> + return 0;
> +}
> +
> +static void ftrace_graph_ret_stub(struct ftrace_graph_ret *trace,
> + struct fgraph_ops *gops)
> +{
> +}
> +
> +static struct fgraph_ops fgraph_stub = {
> + .entryfunc = ftrace_graph_entry_stub,
> + .retfunc = ftrace_graph_ret_stub,
> +};
> +
> +static struct fgraph_ops *fgraph_array[FGRAPH_ARRAY_SIZE] = {
> + [0 ... FGRAPH_ARRAY_SIZE - 1] = &fgraph_stub,
> +};
> static unsigned long fgraph_array_bitmask;
>
> /* LRU index table for fgraph_array */
> static int fgraph_lru_table[FGRAPH_ARRAY_SIZE];
> -static int fgraph_lru_next;
> -static int fgraph_lru_last;
> +static int fgraph_lru_next = -1;
> +static int fgraph_lru_last = -1;
>
> /* Initialize fgraph_lru_table with unused index */
> static void fgraph_lru_init(void)
> {
> - int i;
> + if ((fgraph_lru_next >= 0) && (fgraph_lru_last >= 0))
> + return;
>
> - for (i = 0; i < FGRAPH_ARRAY_SIZE; i++)
> + fgraph_lru_next = fgraph_lru_last = 0;
> +
> + for (int i = 0; i < FGRAPH_ARRAY_SIZE; i++)
> fgraph_lru_table[i] = i;
> }
>
> @@ -483,22 +504,6 @@ int __weak ftrace_disable_ftrace_graph_caller(void)
> }
> #endif
>
> -int ftrace_graph_entry_stub(struct ftrace_graph_ent *trace,
> - struct fgraph_ops *gops)
> -{
> - return 0;
> -}
> -
> -static void ftrace_graph_ret_stub(struct ftrace_graph_ret *trace,
> - struct fgraph_ops *gops)
> -{
> -}
> -
> -static struct fgraph_ops fgraph_stub = {
> - .entryfunc = ftrace_graph_entry_stub,
> - .retfunc = ftrace_graph_ret_stub,
> -};
> -
> static struct fgraph_ops *fgraph_direct_gops = &fgraph_stub;
> DEFINE_STATIC_CALL(fgraph_func, ftrace_graph_entry_stub);
> DEFINE_STATIC_CALL(fgraph_retfunc, ftrace_graph_ret_stub);
> @@ -1250,12 +1255,7 @@ int register_ftrace_graph(struct fgraph_ops *gops)
>
> mutex_lock(&ftrace_lock);
>
> - if (!fgraph_array[0]) {
> - /* The array must always have real data on it */
> - for (i = 0; i < FGRAPH_ARRAY_SIZE; i++)
> - fgraph_array[i] = &fgraph_stub;
> - fgraph_lru_init();
> - }
> + fgraph_lru_init();
>
> i = fgraph_lru_alloc_index();
> if (i < 0 || WARN_ON_ONCE(fgraph_array[i] != &fgraph_stub)) {
prev parent reply other threads:[~2024-09-30 14:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 7:10 [PATCH v2] function_graph: Improve fgraph LRU data initialization Liao Chang
2024-09-30 14:55 ` Steven Rostedt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240930105550.564d5a67@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=liaochang1@huawei.com \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox