[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZVM=q2yPrt34AyiVJYiB1cAu2Y=4zCKkYFZ0N-Ai6BRg@mail.gmail.com>
Date: Mon, 9 Dec 2024 16:23:33 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>, Kan Liang <kan.liang@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users <linux-perf-users@...r.kernel.org>, Andrii Nakryiko <andrii@...nel.org>,
Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
Stephane Eranian <eranian@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
Kees Cook <kees@...nel.org>
Subject: Re: [PATCH v2 2/4] perf lock contention: Run BPF slab cache iterator
On Mon, Dec 9, 2024 at 3:33 PM Arnaldo Carvalho de Melo
<arnaldo.melo@...il.com> wrote:
>
> On Mon, Dec 9, 2024, 8:00 PM Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>>
>> On Mon, Dec 9, 2024 at 12:23 PM Arnaldo Carvalho de Melo
>> <acme@...nel.org> wrote:
>>
>> > and additionally the type is not like the one you added to the barebones
>> > vmlinux.h:
>>
>> > ⬢ [acme@...lbox perf-tools-next]$ git show d82e2e170d1c756b | grep 'struct bpf_iter__kmem_cache {' -A3
>> > +struct bpf_iter__kmem_cache {
>> > + struct kmem_cache *s;
>> > +} __attribute__((preserve_access_index));
>> > +
>> > ⬢ [acme@...lbox perf-tools-next]$
>>
>> > But:
>>
>> > ⬢ [acme@...lbox perf-tools-next]$ uname -a
>> > Linux toolbox 6.13.0-rc2 #1 SMP PREEMPT_DYNAMIC Mon Dec 9 12:33:35 -03 2024 x86_64 GNU/Linux
>> > ⬢ [acme@...lbox perf-tools-next]$ pahole bpf_iter__kmem_cache
>> > struct bpf_iter__kmem_cache {
>> > union {
>> > struct bpf_iter_meta * meta; /* 0 8 */
>> > }; /* 0 8 */
>> > union {
>> > struct kmem_cache * s; /* 8 8 */
>> > }; /* 8 8 */
>> >
>> > /* size: 16, cachelines: 1, members: 2 */
>> > /* last cacheline: 16 bytes */
>> > };
>>
>> > ⬢ [acme@...lbox perf-tools-next]$
>>
>> > Do CO-RE handle this?
>>
>> I don't know exactly what the problem you are running into is, but
>> yes, BPF CO-RE allows handling missing fields, incompatible field type
>> changes, field renames, etc. All without having to break a
>> compilation. See [0] (and one subsection after that) for
>> "documentation" and examples.
>>
>> [0] https://nakryiko.com/posts/bpf-core-reference-guide/#defining-own-co-re-relocatable-type-definitions
>
>
>>
> The doubt is the extra layer of unnamed unions in the BTF for the kernel that's not present in the minimal representation shipped with perf.
anonymous unions or structs are transparent to BPF CO-RE relocation,
so that shouldn't be a problem
>
> - Arnaldo
Powered by blists - more mailing lists