linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Yang Jihong <yangjihong@bytedance.com>,
	peterz@infradead.org, mingo@redhat.com, namhyung@kernel.org,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	jolsa@kernel.org, adrian.hunter@intel.com,
	kan.liang@linux.intel.com, james.clark@arm.com,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH 1/2] perf sched timehist: Fix -g/--call-graph option failure
Date: Sat, 30 Mar 2024 11:48:21 -0300	[thread overview]
Message-ID: <ZggmNWYjBtid_hCZ@x1> (raw)
In-Reply-To: <CAP-5=fWDY9Aj+qHNOuwJ9yE==G=vmCzECXYEZAifOhGHX7yr6w@mail.gmail.com>

On Fri, Mar 29, 2024 at 09:08:01AM -0700, Ian Rogers wrote:
> On Thu, Mar 28, 2024 at 8:02 PM Yang Jihong <yangjihong@bytedance.com> wrote:
> >
> > Hello,
> >
> > Sorry, due to the new email settings, the last reply email was in html
> > format, resend it now.
> >
> > On 3/29/24 00:02, Ian Rogers wrote:
> > > On Wed, Mar 27, 2024 at 10:59 PM Yang Jihong <yangjihong@bytedance.com> wrote:
> > >>
> > >> When perf-sched enables the call-graph recording, sample_type of dummy
> > >> event does not have PERF_SAMPLE_CALLCHAIN, timehist_check_attr() checks
> > >> that the evsel does not have a callchain, and set show_callchain to 0.
> > >>
> > >> Currently perf sched timehist only saves callchain when processing
> > >> sched:sched_switch event, timehist_check_attr() only needs to determine
> > >> whether the event has PERF_SAMPLE_CALLCHAIN.
> > >>
> > >> Before:
> > >>    # perf sched record -g true
> > >>    [ perf record: Woken up 0 times to write data ]
> > >>    [ perf record: Captured and wrote 4.153 MB perf.data (7536 samples) ]
> > >>    # perf sched timehist
> > >>    Samples do not have callchains.
> > >>               time    cpu  task name                       wait time  sch delay   run time
> > >>                            [tid/pid]                          (msec)     (msec)     (msec)
> > >>    --------------- ------  ------------------------------  ---------  ---------  ---------
> > >>      147851.826019 [0000]  perf[285035]                        0.000      0.000      0.000
> > >>      147851.826029 [0000]  migration/0[15]                     0.000      0.003      0.009
> > >>      147851.826063 [0001]  perf[285035]                        0.000      0.000      0.000
> > >>      147851.826069 [0001]  migration/1[21]                     0.000      0.003      0.006
> > >>    <SNIP>
> > >>
> > >> After:
> > >>    # perf sched record -g true
> > >>    [ perf record: Woken up 1 times to write data ]
> > >>    [ perf record: Captured and wrote 2.572 MB perf.data (822 samples) ]
> > >>    # perf sched timehist
> > >>               time    cpu  task name                       wait time  sch delay   run time
> > >>                            [tid/pid]                          (msec)     (msec)     (msec)
> > >>    --------------- ------  ------------------------------  ---------  ---------  ---------
> > >>      144193.035164 [0000]  perf[277062]                        0.000      0.000      0.000    __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion
> > >>      144193.035174 [0000]  migration/0[15]                     0.000      0.003      0.009    __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork
> > >>      144193.035207 [0001]  perf[277062]                        0.000      0.000      0.000    __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion
> > >>      144193.035214 [0001]  migration/1[21]                     0.000      0.003      0.007    __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork
> > >> <SNIP>
> > >
> > > This looks good, should there be a Fixes tag for the sake of backports?
> > >
> > The direct cause is commit 9c95e4ef0657 ("perf evlist: Add
> > evlist__findnew_tracking_event() helper"). perf-record uses
> > evlist__add_aux_dummy() to replace evlist__add_dummy() to add a dummy
> > event. The difference is that evlist__add_aux_dummy() sets
> > no_aux_samples to true (this is expected behavior, for dummy event, no
> > need to sample aux data), resulting in evsel__config() not adding the
> > PERF_SAMPLE_CALLCHAIN bit to dummy's sample_type.
> >
> > In summary, the direct cause is the problem introduced by commit
> > 9c95e4ef0657 ("perf evlist: Add evlist__findnew_tracking_event()
> > helper"), but the root cause is the timehist_check_attr() logic problem,
> > The dummy event itself does not need to have PERF_SAMPLE_CALLCHAIN, so
> > there is no need to check it.
> >
> >
> > So, maybe add fixes-tag:
> >
> > Fixes: 9c95e4ef0657 ("perf evlist: Add evlist__findnew_tracking_event()
> > helper")
> >
> > If it is ok, I will send v2 version with this fixes-tag.
> 
> I think the maintainer can add the fixes tag when they add the reviewed-by tag:

I usually do this, but if the submitter does it I'll have just to check
that it is the right tag, helps a bit in processing.

- Arnaldo
 
> Reviewed-by: Ian Rogers <irogers@google.com>
> 
> Thanks,
> Ian
> 
> > Thanks,
> > Yang

  reply	other threads:[~2024-03-30 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28  5:58 [PATCH 1/2] perf sched timehist: Fix -g/--call-graph option failure Yang Jihong
2024-03-28  5:58 ` [PATCH 2/2] perf evsel: Use evsel__name_is() helper Yang Jihong
2024-03-28 16:06   ` Ian Rogers
2024-03-28 16:02 ` [PATCH 1/2] perf sched timehist: Fix -g/--call-graph option failure Ian Rogers
2024-03-29  3:02   ` [External] " Yang Jihong
2024-03-29 16:08     ` Ian Rogers
2024-03-30 14:48       ` Arnaldo Carvalho de Melo [this message]
2024-04-01  1:50         ` Yang Jihong

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=ZggmNWYjBtid_hCZ@x1 \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=yangjihong@bytedance.com \
    /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;
as well as URLs for NNTP newsgroup(s).