All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	cgroups@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org,
	Song Liu <songliubraving@fb.com>,
	bpf@vger.kernel.org
Subject: Re: [PATCH] perf stat: Support old kernels for bperf cgroup counting
Date: Fri, 30 Sep 2022 15:48:37 -0700	[thread overview]
Message-ID: <CAEf4BzZhHYYOmNhLdrpsXSDE5kaXvgSN00X-8aAySDwAKX0RCw@mail.gmail.com> (raw)
In-Reply-To: <20220922041435.709119-1-namhyung@kernel.org>

On Wed, Sep 21, 2022 at 9:21 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> The recent change in the cgroup will break the backward compatiblity in
> the BPF program.  It should support both old and new kernels using BPF
> CO-RE technique.
>
> Like the task_struct->__state handling in the offcpu analysis, we can
> check the field name in the cgroup struct.
>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> Arnaldo, I think this should go through the cgroup tree since it depends
> on the earlier change there.  I don't think it'd conflict with other
> perf changes but please let me know if you see any trouble, thanks!
>
>  tools/perf/util/bpf_skel/bperf_cgroup.bpf.c | 29 ++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c b/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c
> index 488bd398f01d..4fe61043de04 100644
> --- a/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c
> +++ b/tools/perf/util/bpf_skel/bperf_cgroup.bpf.c
> @@ -43,12 +43,39 @@ struct {
>         __uint(value_size, sizeof(struct bpf_perf_event_value));
>  } cgrp_readings SEC(".maps");
>
> +/* new kernel cgroup definition */
> +struct cgroup___new {
> +       int level;
> +       struct cgroup *ancestors[];
> +} __attribute__((preserve_access_index));
> +
> +/* old kernel cgroup definition */
> +struct cgroup___old {
> +       int level;
> +       u64 ancestor_ids[];
> +} __attribute__((preserve_access_index));
> +
>  const volatile __u32 num_events = 1;
>  const volatile __u32 num_cpus = 1;
>
>  int enabled = 0;
>  int use_cgroup_v2 = 0;
>
> +static inline __u64 get_cgroup_v1_ancestor_id(struct cgroup *cgrp, int level)
> +{
> +       /* recast pointer to capture new type for compiler */
> +       struct cgroup___new *cgrp_new = (void *)cgrp;
> +
> +       if (bpf_core_field_exists(cgrp_new->ancestors)) {
> +               return BPF_CORE_READ(cgrp_new, ancestors[level], kn, id);

have you checked generated BPF code for this ancestors[level] access?
I'd expect CO-RE relocation for finding ancestors offset and then just
normal + level * 8 arithmetic, but would be nice to confirm. Apart
from this, looks good to me:

Acked-by: Andrii Nakryiko <andrii@kernel.org>


> +       } else {
> +               /* recast pointer to capture old type for compiler */
> +               struct cgroup___old *cgrp_old = (void *)cgrp;
> +
> +               return BPF_CORE_READ(cgrp_old, ancestor_ids[level]);
> +       }
> +}
> +
>  static inline int get_cgroup_v1_idx(__u32 *cgrps, int size)
>  {
>         struct task_struct *p = (void *)bpf_get_current_task();
> @@ -70,7 +97,7 @@ static inline int get_cgroup_v1_idx(__u32 *cgrps, int size)
>                         break;
>
>                 // convert cgroup-id to a map index
> -               cgrp_id = BPF_CORE_READ(cgrp, ancestors[i], kn, id);
> +               cgrp_id = get_cgroup_v1_ancestor_id(cgrp, i);
>                 elem = bpf_map_lookup_elem(&cgrp_idx, &cgrp_id);
>                 if (!elem)
>                         continue;
> --
> 2.37.3.968.ga6b4b080e4-goog
>

  parent reply	other threads:[~2022-09-30 22:48 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 19:05 [PATCH cgroup/for-5.20] cgroup: Replace cgroup->ancestor_ids[] with ->ancestors[] Tejun Heo
2022-07-29 19:05 ` Tejun Heo
2022-07-29 20:30 ` Namhyung Kim
2022-07-29 20:30   ` Namhyung Kim
2022-07-29 20:58 ` [PATCH v2 " Tejun Heo
2022-07-29 20:58   ` Tejun Heo
2022-07-29 22:42   ` Michal Koutný
2022-07-29 22:42     ` Michal Koutný
2022-07-29 23:02     ` Tejun Heo
2022-07-29 23:02       ` Tejun Heo
2022-07-29 23:10   ` [PATCH v3 " Tejun Heo
2022-08-15 21:17     ` Tejun Heo
2022-09-22  4:05       ` Namhyung Kim
2022-09-22  4:05         ` Namhyung Kim
2022-09-22  4:14         ` [PATCH] perf stat: Support old kernels for bperf cgroup counting Namhyung Kim
2022-09-22  4:14           ` Namhyung Kim
2022-09-24  3:22           ` Tejun Heo
2022-09-30 20:30             ` Namhyung Kim
2022-09-30 20:30               ` Namhyung Kim
2022-09-30 21:43           ` Jiri Olsa
2022-09-30 21:56             ` Namhyung Kim
2022-09-30 21:56               ` Namhyung Kim
2022-09-30 22:00               ` Arnaldo Carvalho de Melo
2022-09-30 22:00                 ` Arnaldo Carvalho de Melo
2022-09-30 22:11                 ` Namhyung Kim
2022-09-30 22:11                   ` Namhyung Kim
2022-10-01 13:57               ` Jiri Olsa
2022-10-01 13:57                 ` Jiri Olsa
2022-09-30 22:48           ` Andrii Nakryiko [this message]
2022-10-01  2:31             ` Namhyung Kim
2022-10-05 22:36               ` Andrii Nakryiko
2022-10-05 22:36                 ` Andrii Nakryiko
2022-10-01 13:58           ` Jiri Olsa
2022-10-01 13:58             ` Jiri Olsa
2022-10-10 23:59           ` Tejun Heo
2022-10-11  5:24             ` Namhyung Kim
2022-10-11  5:24               ` Namhyung Kim
2022-10-11  5:28             ` [PATCH v2] " Namhyung Kim
2022-10-11  5:28               ` Namhyung Kim
2022-10-11 16:53               ` Tejun Heo
2022-10-14 13:27                 ` Arnaldo Carvalho de Melo
2022-10-14 13:30                   ` Arnaldo Carvalho de Melo
2022-10-14 13:30                     ` Arnaldo Carvalho de Melo
2022-10-14 16:40                   ` Tejun Heo
2022-10-14 16:40                     ` Tejun Heo
2022-10-14 17:10                     ` Arnaldo Carvalho de Melo
2022-10-14 17:10                       ` Arnaldo Carvalho de Melo

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=CAEf4BzZhHYYOmNhLdrpsXSDE5kaXvgSN00X-8aAySDwAKX0RCw@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=acme@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=namhyung@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=tj@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 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.