[PATCH] perf stat: Fix aggregation of cgroup events

[PATCH] perf stat: Fix aggregation of cgroup events

[Namhyung Kim]

I got a report that perf stat with BPF and cgroup is broken with
aggregation like per-socket or node.  On my machine, running the
following command shows the problem.

  $ sudo perf stat -a --bpf-counters --per-socket -e cycles \
    --for-each-cgroup /user.slice,/system.slice  sleep 1

   Performance counter stats for 'system wide':

  S0       12      <not counted>      cpu_atom/cycles/                 user.slice
  S0       16      <not counted>      cpu_core/cycles/                 user.slice
  S0       12      <not counted>      cpu_atom/cycles/                 system.slice
  S0       16      <not counted>      cpu_core/cycles/                 system.slice

         1.002798147 seconds time elapsed

That's because there's a logic to make the whole event failed if result
from any CPU looks bad when aggregation is enabled.  Normally it
considers bad when an event has no enabled and running time.  But it's
possible for a cgroup event to have no chance to run on some CPU during
the window and then it will have 0 enabled and running time.  Let's not
treat them as errors.

After the fix, the same command produces:

   Performance counter stats for 'system wide':

  S0       12          5,094,112      cpu_atom/cycles/                 user.slice
  S0       16         28,075,944      cpu_core/cycles/                 user.slice
  S0       12          1,516,568      cpu_atom/cycles/                 system.slice
  S0       16          5,569,575      cpu_core/cycles/                 system.slice

         1.003231856 seconds time elapsed

Reported-by: Chun-Tse Shao <ctshao@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
 tools/perf/util/stat.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index 25f31a17436828aa..6da3dbbde0e2ad8d 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -381,6 +381,10 @@ static bool evsel__count_has_error(struct evsel *evsel,
 	if (config->aggr_mode == AGGR_GLOBAL)
 		return false;
 
+	/* cgroup events may not be scheduled on some CPUs */
+	if (evsel->cgrp)
+		return false;
+
 	/* it's considered ok when it actually ran */
 	if (count->ena != 0 && count->run != 0)
 		return false;
-- 
2.55.0

Re: [PATCH] perf stat: Fix aggregation of cgroup events

[sashiko-bot]

> I got a report that perf stat with BPF and cgroup is broken with
> aggregation like per-socket or node.  On my machine, running the
> following command shows the problem.
> 
>   $ sudo perf stat -a --bpf-counters --per-socket -e cycles \
>     --for-each-cgroup /user.slice,/system.slice  sleep 1
> 
>    Performance counter stats for 'system wide':
> 
>   S0       12      <not counted>      cpu_atom/cycles/                 user.slice
>   S0       16      <not counted>      cpu_core/cycles/                 user.slice
>   S0       12      <not counted>      cpu_atom/cycles/                 system.slice
>   S0       16      <not counted>      cpu_core/cycles/                 system.slice
> 
>          1.002798147 seconds time elapsed
> [ ... ]
> 
>          1.003231856 seconds time elapsed
> 
> Reported-by: Chun-Tse Shao <ctshao@google.com>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002054832.64980-1-namhyung@kernel.org?part=1

Re: [PATCH] perf stat: Fix aggregation of cgroup events

[Chun-Tse Shao]

On Thu, Oct 1, 2026 at 10:48 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> I got a report that perf stat with BPF and cgroup is broken with
> aggregation like per-socket or node.  On my machine, running the
> following command shows the problem.
>
>   $ sudo perf stat -a --bpf-counters --per-socket -e cycles \
>     --for-each-cgroup /user.slice,/system.slice  sleep 1
>
>    Performance counter stats for 'system wide':
>
>   S0       12      <not counted>      cpu_atom/cycles/                 user.slice
>   S0       16      <not counted>      cpu_core/cycles/                 user.slice
>   S0       12      <not counted>      cpu_atom/cycles/                 system.slice
>   S0       16      <not counted>      cpu_core/cycles/                 system.slice
>
>          1.002798147 seconds time elapsed
>
> That's because there's a logic to make the whole event failed if result
> from any CPU looks bad when aggregation is enabled.  Normally it
> considers bad when an event has no enabled and running time.  But it's
> possible for a cgroup event to have no chance to run on some CPU during
> the window and then it will have 0 enabled and running time.  Let's not
> treat them as errors.
>
> After the fix, the same command produces:
>
>    Performance counter stats for 'system wide':
>
>   S0       12          5,094,112      cpu_atom/cycles/                 user.slice
>   S0       16         28,075,944      cpu_core/cycles/                 user.slice
>   S0       12          1,516,568      cpu_atom/cycles/                 system.slice
>   S0       16          5,569,575      cpu_core/cycles/                 system.slice
>
>          1.003231856 seconds time elapsed
>
> Reported-by: Chun-Tse Shao <ctshao@google.com>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Tested-by: Chun-Tse Shao <ctshao@google.com>

Thanks for the fix!


-CT

> ---
>  tools/perf/util/stat.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
> index 25f31a17436828aa..6da3dbbde0e2ad8d 100644
> --- a/tools/perf/util/stat.c
> +++ b/tools/perf/util/stat.c
> @@ -381,6 +381,10 @@ static bool evsel__count_has_error(struct evsel *evsel,
>         if (config->aggr_mode == AGGR_GLOBAL)
>                 return false;
>
> +       /* cgroup events may not be scheduled on some CPUs */
> +       if (evsel->cgrp)
> +               return false;
> +
>         /* it's considered ok when it actually ran */
>         if (count->ena != 0 && count->run != 0)
>                 return false;
> --
> 2.55.0
>