All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Jihong <yangjihong@bytedance.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ian Rogers <irogers@google.com>
Cc: 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: Mon, 1 Apr 2024 09:50:02 +0800	[thread overview]
Message-ID: <3be0a35e-9e10-49b5-8fa2-71f6ddc6f704@bytedance.com> (raw)
In-Reply-To: <ZggmNWYjBtid_hCZ@x1>

Hello,

On 3/30/24 22:48, Arnaldo Carvalho de Melo wrote:
> 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.
Okay, will send v2 version.

> 
> - Arnaldo
>   
>> Reviewed-by: Ian Rogers <irogers@google.com>
Thanks for reviewed-by tag.

Thanks,
Yang

      reply	other threads:[~2024-04-01  1:50 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
2024-04-01  1:50         ` Yang Jihong [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=3be0a35e-9e10-49b5-8fa2-71f6ddc6f704@bytedance.com \
    --to=yangjihong@bytedance.com \
    --cc=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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.