[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z6ozXeOaZJMNRy3x@tassilo>
Date: Mon, 10 Feb 2025 09:11:57 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: namhyung@...nel.org, irogers@...gle.com,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v5 0/8] perf report: Add latency and parallelism profiling
> > 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.
>
> I don't think this is a solution :(
>
> I provided lots of rationale for making this latency profiling enabled
> by default in this patch series for this reason. If we just capture
> context switches, then we can show both overhead and latency, even if
> we sort by overhead by default, people would still see the latency
> column and may start thinking/asking questions.
> But this is not happening, so mostly people on this thread will know about it :)
Maybe something that could be done is to have some higher level configurations
for perf report that are easier to understand.
This kind of already exists e.g. in perf mem report which is just a
wrapper around perf report with some magic flags.
In this case you could have perf latency report (or maybe some other
syntax like perf report --mode latency)
There are a few others that would make sense, like basic time series
or disabling children aggregation.
Another possibility would be to find a heuristic where perf report
can detect that a latency problem might be there (e.g. varying
usage of CPUs) and suggest it automatically.
-Andi
Powered by blists - more mailing lists