All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Song Liu <songliubraving@fb.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>, Ian Rogers <irogers@google.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 3/3] perf stat: Enable BPF counter with --for-each-cgroup
Date: Thu, 24 Jun 2021 15:06:46 -0700	[thread overview]
Message-ID: <CAM9d7chvmH0r85Ezx6kTyDsTM5nWSUDoOjnkEgTkKjE2U5LrVA@mail.gmail.com> (raw)
In-Reply-To: <A157287B-5DE5-4D8D-B8BE-FF18BFAAC16E@fb.com>

On Thu, Jun 24, 2021 at 2:41 PM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jun 24, 2021, at 2:01 PM, Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Thu, Jun 24, 2021 at 9:20 AM Song Liu <songliubraving@fb.com> wrote:
> >>>>> +
> >>>>> +// single set of global perf events to measure
> >>>>> +struct {
> >>>>> +     __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
> >>>>> +     __uint(key_size, sizeof(__u32));
> >>>>> +     __uint(value_size, sizeof(int));
> >>>>> +     __uint(max_entries, 1);
> >>>>> +} events SEC(".maps");
> >>>>> +
> >>>>> +// from logical cpu number to event index
> >>>>> +// useful when user wants to count subset of cpus
> >>>>> +struct {
> >>>>> +     __uint(type, BPF_MAP_TYPE_HASH);
> >>>>> +     __uint(key_size, sizeof(__u32));
> >>>>> +     __uint(value_size, sizeof(__u32));
> >>>>> +     __uint(max_entries, 1);
> >>>>> +} cpu_idx SEC(".maps");
> >>>>
> >>>> How about we make cpu_idx a percpu array and use 0,1 for
> >>>> disable/enable profiling on this cpu?
> >>>
> >>> No, it's to calculate an index to the cgrp_readings map which
> >>> has the event x cpu x cgroup number of elements.
> >>>
> >>> It controls enabling events with a global (bss) variable.
> >>
> >> If we make cgrp_idx a per cpu array, we probably don't need the
> >> cpu_idx map?
> >
> > Right.

Maybe not.  Sometimes we want to profile a subset of cpus only.
In that case, cpu != idx then I think we still need this.


> >
> >>
> >>>
> >>>>
> >>>>> +
> >>>>> +// from cgroup id to event index
> >>>>> +struct {
> >>>>> +     __uint(type, BPF_MAP_TYPE_HASH);
> >>>>> +     __uint(key_size, sizeof(__u64));
> >>>>> +     __uint(value_size, sizeof(__u32));
> >>>>> +     __uint(max_entries, 1);
> >>>>> +} cgrp_idx SEC(".maps");
> >>>>> +
> >>>>> +// per-cpu event snapshots to calculate delta
> >>>>> +struct {
> >>>>> +     __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
> >>>>> +     __uint(key_size, sizeof(__u32));
> >>>>> +     __uint(value_size, sizeof(struct bpf_perf_event_value));
> >>>>> +} prev_readings SEC(".maps");
> >>>>> +
> >>>>> +// aggregated event values for each cgroup
> >>>>> +// will be read from the user-space
> >>>>> +struct {
> >>>>> +     __uint(type, BPF_MAP_TYPE_ARRAY);
> >>>>> +     __uint(key_size, sizeof(__u32));
> >>>>> +     __uint(value_size, sizeof(struct bpf_perf_event_value));
> >>>>> +} cgrp_readings SEC(".maps");
> >>>>
> >>>> Maybe also make this a percpu array? This should make the BPF program
> >>>> faster.
> >>>
> >>> Maybe.  But I don't know how to access the elements
> >>> in a per-cpu map from userspace.
> >>
> >> Please refer to bperf__read() reading accum_readings. Basically, we read
> >> one index of all CPUs with one bpf_map_lookup_elem().
> >
> > Thanks!  So when I use a per-cpu array with 3 elements, I can access
> > to cpu/elem entries in a row like below, right?
> >
> >  0/0, 0/1, 0/2, 1/0, 1/1, 1/2, 2/0, 2/1, 2/2, 3/0, ...
>
> I am not sure I am following here.
>
> Say the system have 10 cpus, and the array has 3 elements. We can do:
>
>         __u32 values[10];  /* assuming both key and value are __u32 */
>         __u32 elem;
>         int cpu;
>
>         for (elem = 0; elem < 3; elem++) {
>                 bpf_map_lookup_elem(map_fd, &elem, values);
>                 for (cpu = 0; cpu < 10; cpu++)
>                         values[cpu] /* this is the value for cpu/elem */
>         }

Thanks for the explanation, I didn't think that way.
I thought it like below:

    __u32 elem, value;

    for (elem = 0; elem < 3 * 10; elem++) {
        bpf_map_lookup_elem(map_fd, &elem, &value);
    }

So in this case, the actual value size is like below, right?

  value-size = map-value-size * number-of-cpu

Thanks,
Namhyung

  reply	other threads:[~2021-06-24 22:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22  7:12 [PATCHSET v3 0/3] perf stat: Enable BPF counters with --for-each-cgroup Namhyung Kim
2021-06-22  7:12 ` [PATCH 1/3] perf tools: Add read_cgroup_id() function Namhyung Kim
2021-06-22  7:12 ` [PATCH 2/3] perf tools: Add cgroup_is_v2() helper Namhyung Kim
2021-06-22  7:12 ` [PATCH 3/3] perf stat: Enable BPF counter with --for-each-cgroup Namhyung Kim
2021-06-24  4:54   ` Song Liu
2021-06-24  5:49     ` Namhyung Kim
2021-06-24 16:20       ` Song Liu
2021-06-24 21:01         ` Namhyung Kim
2021-06-24 21:40           ` Song Liu
2021-06-24 22:06             ` Namhyung Kim [this message]
2021-06-24 22:15               ` Song Liu
2021-06-24 22:21                 ` Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2021-06-15  1:17 [PATCHSET v2 0/3] perf stat: Enable BPF counters " Namhyung Kim
2021-06-15  1:17 ` [PATCH 3/3] perf stat: Enable BPF counter " Namhyung Kim

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=CAM9d7chvmH0r85Ezx6kTyDsTM5nWSUDoOjnkEgTkKjE2U5LrVA@mail.gmail.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    /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.