[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180305231600.GB8824@sejong>
Date: Tue, 6 Mar 2018 08:16:00 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: "Du, Changbin" <changbin.du@...el.com>, acme@...nel.org,
peterz@...radead.org, mingo@...hat.com,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
kernel-team@....com
Subject: Re: [RESEND PATCH] perf sched map: re-annotate shortname if thread
comm changed
Hi,
On Mon, Mar 05, 2018 at 11:37:54PM +0100, Jiri Olsa wrote:
> On Mon, Mar 05, 2018 at 03:11:36PM +0800, Du, Changbin wrote:
>
> SNIP
>
> > > > on the other hand it's simple enough and looks
> > > > like generic solution would be more tricky
> > >
> > > What about adding perf_sched__process_comm() to set it in the
> > > thread::priv?
> > >
> > I can be done, then thread->comm_changed moves to thread_runtime->comm_changed.
> > Draft code as below. It is also a little tricky.
> >
> > +int perf_sched__process_comm(struct perf_tool *tool __maybe_unused,
> > + union perf_event *event,
> > + struct perf_sample *sample,
> > + struct machine *machine)
> > +{
> > + struct thread *thread;
> > + struct thread_runtime *r;
> > +
> > + perf_event__process_comm(tool, event, sample, machine);
> > +
> > + thread = machine__findnew_thread(machine, pid, tid);
>
> should you use machine__find_thread in here?
Yep, perf_event__process_comm() already created a new thread if needed.
And the return value of it should be checked.
>
> > + if (thread) {
> > + r = thread__priv(thread);
> > + if (r)
> > + r->comm_changed = true;
> > + thread__put(thread);
> > + }
Missing return.
> > +}
> > +
> > static int perf_sched__read_events(struct perf_sched *sched)
> > {
> > const struct perf_evsel_str_handler handlers[] = {
> > @@ -3291,7 +3311,7 @@ int cmd_sched(int argc, const char **argv)
> > struct perf_sched sched = {
> > .tool = {
> > .sample = perf_sched__process_tracepoint_sample,
> > - .comm = perf_event__process_comm,
> > + .comm = perf_sched__process_comm,
> >
> >
> > But I'd keep 'comm_changed' where 'shortname' is defined. I think they should appears
> > togother. And 'shortname' is only used by sched command, too.
>
> they can both go to struct thread_runtime then
Agreed.
>
> >
> > So I still prefer my privous simpler change. Thanks!
>
> I was wrong thinking that the amount of code
> making it sched specific would be biger
>
> we're trying to keep the core structs generic,
> so this one fits better
Right.
Thanks,
Namhyung
Powered by blists - more mailing lists