From: Steven Rostedt <email@example.com>
To: Masami Hiramatsu <firstname.lastname@example.org>
Cc: email@example.com, Ingo Molnar <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Tom Zanussi <firstname.lastname@example.org>,
Namhyung Kim <email@example.com>
Subject: Re: [PATCH v2 2/2] tracing: Allow execnames to be passed as args for synthetic events
Date: Thu, 22 Jul 2021 21:24:38 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Fri, 23 Jul 2021 10:11:33 +0900
Masami Hiramatsu <email@example.com> wrote:
> I understand. As far as I can see the code, it looks a bit complicated.
> To simplify it, I need to understand the spec for "hist_field"
> for keys and for vars. And maybe need to split both case.
I'll give you a hint that took me a bit to figure out.
1) The execname is saved at the start of the histogram and not by one
of the ->fn() functions.
It's saved by hist_trigger_elt_data_init() if the elt_data->comm is
allocated. That function is part of the "tracing_map_ops" which gets
assigned by tracing_map_create() (in tracing_map.c) as the "elt_init"
function, which is called when getting a new elt element by
2) That elt_data->comm is only allocated if it finds a "hist_field"
that has HIST_FIELD_FL_EXECNAME flag set. It currently only looks for
that flag in the "keys" fields, which means that .execname is useless
for everything else. This patch changed it to search all hist_fields so
that it can find that flag if a variable has it set (which I added).
> > I found this to be the least intrusive solution.
> > Maybe Tom has a better idea, but I don't have any more time to work on
> > it, and I really want this feature for the next merge window.
> > If you can make it work, and have time to play with it, I'm happy to
> > take an alternative :-)
> Me neither at least this moment, need more investigation. Let me try.
Great! I can hold off on adding this. Or I can add it, and if you come
up with a better solution, we can just swap it.
next prev parent reply other threads:[~2021-07-23 1:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 14:27 [PATCH v2 0/2] tracing: Allow execnames to be passed as args for synthetic events Steven Rostedt
2021-07-22 14:27 ` [PATCH v2 1/2] tracing: Have histogram types be constant when possible Steven Rostedt
2021-07-22 15:24 ` Masami Hiramatsu
2021-07-22 22:11 ` Tom Zanussi
2021-07-22 14:27 ` [PATCH v2 2/2] tracing: Allow execnames to be passed as args for synthetic events Steven Rostedt
2021-07-22 16:19 ` Masami Hiramatsu
2021-07-22 16:32 ` Steven Rostedt
2021-07-23 1:11 ` Masami Hiramatsu
2021-07-23 1:22 ` Masami Hiramatsu
2021-07-23 1:26 ` Steven Rostedt
2021-07-23 1:24 ` Steven Rostedt [this message]
2021-07-24 10:31 ` Masami Hiramatsu
2021-07-25 2:18 ` Masami Hiramatsu
2021-07-25 3:45 ` Masami Hiramatsu
2021-07-26 13:28 ` Steven Rostedt
2021-07-27 22:54 ` Masami Hiramatsu
2021-07-22 22:09 ` Tom Zanussi
2021-07-22 15:14 ` [PATCH v2 0/2] " Steven Rostedt
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).