[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200910155736.jadhmqvnqquammpn@two.firstfloor.org>
Date: Thu, 10 Sep 2020 08:57:38 -0700
From: Andi Kleen <andi@...stfloor.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Stephane Eranian <eranian@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <andi@...stfloor.org>,
Ian Rogers <irogers@...gle.com>
Subject: Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option
On Tue, Sep 08, 2020 at 01:42:24PM +0900, Namhyung Kim wrote:
> When we profile cgroup events with perf stat, it's very annoying to
> specify events and cgroups on the command line as it requires the
> mapping between events and cgroups. (Note that perf record can use
> cgroup sampling but it's not usable for perf stat).
The problem is real, but I don't really like your solution.
The option is ugly. Should rather be solved with some suitable
syntax in the expression parser to express: apply to all,
instead of adding adhoc options like this.
There are some additional problems that really need to be eventually
solved too:
- If you use the old syntax and some cgroups are not covered you don't
get any warning. At least that should be fixed too.
- And of course if everything works it is still very slow for the kernel
because there are so many perf events to handle. Long term we probably
need some more flexible way to just specify for given perf events which set of
cgroups they should apply, so that sharing and low overhead monitoring
of many cgroups is possible I hate to say it, but maybe some eBPF filter
is the solution here.
-Andi
Powered by blists - more mailing lists