From: Andi Kleen <ak@linux.intel.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: namhyung@kernel.org, irogers@google.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH v5 0/8] perf report: Add latency and parallelism profiling
Date: Fri, 7 Feb 2025 10:30:45 -0800 [thread overview]
Message-ID: <Z6ZRVeoFxT0NV9yb@tassilo> (raw)
In-Reply-To: <CACT4Y+awFXT2j+HMeAy2RKnoBzb--+heFzJUoBZWp9iJevy1Dw@mail.gmail.com>
> > I assume it just works, but might be worth checking.
>
> Yes, it seems to just work as one would assume. Things just combine as intended.
Great.
>
> > It was intended to address some of these issues too.
>
> What issue? Latency profiling? I wonder what approach you had in mind?
The problem with gaps in parallelism is usually how things change
over time. If you have e.g. idle periods they tend to look different
in the profile. with the full aggregation you don't see it, but with
a time series it tends to stand out.
But yes that approach usually only works for large gaps. I guess
yours is better for more fine grained issues.
And I guess it might not be the most intutive for less experienced
users.
This is BTW actually a case for using a perf data GUI like hotspot or
vtune which can visualize this better and you can zoom arbitrarily.
Standard perf has only timechart for it, but it's a bit clunky to use
and only shows the reschedules.
> Also (1) user still needs to understand the default profile is wrong,
> (2) be proficient with perf features, (3) manually aggregate lots of
> data (time slicing increases amount of data in the profile X times),
> (4) deal with inaccuracy caused by edge effects (e.g. slice is 1s, but
> program phase changed mid-second).
If you're lucky and the problem is not long tail you can use a high
percentage cut off (--percent-limit) to eliminate most of the data.
Then you just have "topN functions over time" which tends to be quite
readable. One drawback of that approach is that it doesn't show
the "other", but perhaps we'll fix that one day.
But yes that perf has too many options and is not intuitive and most
people miss most of the features is an inherent problem. I don't have
a good solution for that unfortunately, other than perhaps better
documentation.
>
> But it does open some interesting capabilities in combination with a
> latency profile, e.g. the following shows how parallelism was changing
> over time.
>
> for perf make profile:
Very nice! Looks useful.
Perhaps add that variant to tips.txt too.
>
> perf report -F time,latency,parallelism --time-quantum=1s
>
> # Time Latency Parallelism
> # ............ ........ ...........
> #
> 1795957.0000 1.42% 1
> 1795957.0000 0.07% 2
> 1795957.0000 0.01% 3
> 1795957.0000 0.00% 4
>
> 1795958.0000 4.82% 1
> 1795958.0000 0.11% 2
> 1795958.0000 0.00% 3
> ...
> 1795964.0000 1.76% 2
> 1795964.0000 0.58% 4
> 1795964.0000 0.45% 1
> 1795964.0000 0.23% 10
> 1795964.0000 0.21% 6
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
> Here it finally started running on more than 1 CPU.
-Andi
next prev parent reply other threads:[~2025-02-07 18:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 16:27 [PATCH v5 0/8] perf report: Add latency and parallelism profiling Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 1/8] perf report: Add machine parallelism Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 2/8] perf report: Add parallelism sort key Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 3/8] perf report: Switch filtered from u8 to u16 Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 4/8] perf report: Add parallelism filter Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 5/8] perf report: Add latency output field Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 6/8] perf report: Add --latency flag Dmitry Vyukov
2025-02-07 3:44 ` Namhyung Kim
2025-02-07 7:23 ` Dmitry Vyukov
2025-02-11 1:02 ` Namhyung Kim
2025-02-11 8:30 ` Dmitry Vyukov
2025-02-11 8:42 ` Dmitry Vyukov
2025-02-11 17:42 ` Namhyung Kim
2025-02-11 20:23 ` Dmitry Vyukov
2025-02-12 19:47 ` Namhyung Kim
2025-02-13 9:09 ` Dmitry Vyukov
2025-02-07 3:53 ` Namhyung Kim
2025-02-07 11:42 ` Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 7/8] perf report: Add latency and parallelism profiling documentation Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 8/8] perf hist: Shrink struct hist_entry size Dmitry Vyukov
2025-02-06 18:30 ` [PATCH v5 0/8] perf report: Add latency and parallelism profiling Andi Kleen
2025-02-06 18:41 ` Dmitry Vyukov
2025-02-06 18:51 ` Ian Rogers
2025-02-07 3:57 ` Namhyung Kim
2025-02-07 11:44 ` Dmitry Vyukov
2025-02-06 18:57 ` Andi Kleen
2025-02-06 19:07 ` Andi Kleen
2025-02-07 8:16 ` Dmitry Vyukov
2025-02-07 18:30 ` Andi Kleen [this message]
2025-02-10 7:17 ` Dmitry Vyukov
2025-02-10 17:11 ` Andi Kleen
2025-02-13 9:09 ` Dmitry Vyukov
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=Z6ZRVeoFxT0NV9yb@tassilo \
--to=ak@linux.intel.com \
--cc=acme@kernel.org \
--cc=dvyukov@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@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;
as well as URLs for NNTP newsgroup(s).