All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>
Subject: Re: [RFC bpf-next 0/2] bpf: Fix BTF data for modules
Date: Wed, 27 Oct 2021 10:53:55 -0700	[thread overview]
Message-ID: <CAEf4BzYP8eK0qxF+1UK7=TZ+vFRVMfmnm9AN=B2JHROoDwaHeg@mail.gmail.com> (raw)
In-Reply-To: <YXkTihiRKKJIc9M6@krava>

On Wed, Oct 27, 2021 at 1:53 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Tue, Oct 26, 2021 at 09:12:31PM -0700, Andrii Nakryiko wrote:
> > On Tue, Oct 26, 2021 at 5:03 AM Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Mon, Oct 25, 2021 at 09:54:48PM -0700, Andrii Nakryiko wrote:
> > > > On Sat, Oct 23, 2021 at 5:05 AM Jiri Olsa <jolsa@redhat.com> wrote:
> > > > >
> > > > > hi,
> > > > > I'm trying to enable BTF for kernel module in fedora,
> > > > > and I'm getting big increase on modules sizes on s390x arch.
> > > > >
> > > > > Size of modules in total - kernel dir under /lib/modules/VER/
> > > > > from kernel-core and kernel-module packages:
> > > > >
> > > > >                current   new
> > > > >       aarch64      60M   76M
> > > > >       ppc64le      53M   66M
> > > > >       s390x        21M   41M
> > > > >       x86_64       64M   79M
> > > > >
> > > > > The reason for higher increase on s390x was that dedup algorithm
> > > > > did not detect some of the big kernel structs like 'struct module',
> > > > > so they are duplicated in the kernel module BTF data. The s390x
> > > > > has many small modules that increased significantly in size because
> > > > > of that even after compression.
> > > > >
> > > > > First issues was that the '--btf_gen_floats' option is not passed
> > > > > to pahole for kernel module BTF generation.
> > > > >
> > > > > The other problem is more tricky and is the reason why this patchset
> > > > > is RFC ;-)
> > > > >
> > > > > The s390x compiler generates multiple definitions of the same struct
> > > > > and dedup algorithm does not seem to handle this at the moment.
> > > > >
> > > > > I put the debuginfo and btf dump of the s390x pnet.ko module in here:
> > > > >   http://people.redhat.com/~jolsa/kmodbtf/
> > > > >
> > > > > Please let me know if you'd like to see other info/files.
> > > > >
> > > >
> > > > Hard to tell what's going on without vmlinux itself. Can you upload a
> > > > corresponding kernel image with BTF in it?
> > >
> > > sure, uploaded
> > >
> >
> > vmlinux.btfdump:
> >
> > [174] FLOAT 'float' size=4
> > [175] FLOAT 'double' size=8
> >
> > VS
> >
> > pnet.btfdump:
> >
> > [89318] INT 'float' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> > [89319] INT 'double' size=8 bits_offset=0 nr_bits=64 encoding=(none)
>
> ugh, that's with no fix applied, sry
>
> I applied the first patch and uploaded new files
>
> now when I compare the 'module' struct from vmlinux:
>
>         [885] STRUCT 'module' size=1280 vlen=70
>
> and same one from pnet.ko:
>
>         [89323] STRUCT 'module' size=1280 vlen=70
>
> they seem to completely match, all the fields
> and yet it still appears in the kmod's BTF
>

Ok, now struct module is identical down to the types referenced from
the fields, which means it should have been deduplicated completely.
This will require a more time-consuming debugging, though, so I'll put
it on my TODO list for now. If you get to this earlier, see where the
equivalence check fails in btf_dedup (sprinkle debug outputs around to
see what's going on).

> thanks,
> jirka
>
> >
> >
> > > jirka
> > >
> > > >
> > > > > I found code in dedup that seems to handle such situation for arrays,
> > > > > and added 'some' fix for structs. With that change I can no longer
> > > > > see vmlinux's structs in kernel module BTF data, but I have no idea
> > > > > if that breaks anything else.
> > > > >
> > > > > thoughts? thanks,
> > > > > jirka
> > > > >
> > > > >
> > > > > ---
> > > > > Jiri Olsa (2):
> > > > >       kbuild: Unify options for BTF generation for vmlinux and modules
> > > > >       bpf: Add support to detect and dedup instances of same structs
> > > > >
> > > > >  Makefile                  |  3 +++
> > > > >  scripts/Makefile.modfinal |  2 +-
> > > > >  scripts/link-vmlinux.sh   | 11 +----------
> > > > >  scripts/pahole-flags.sh   | 20 ++++++++++++++++++++
> > > > >  tools/lib/bpf/btf.c       | 12 ++++++++++--
> > > > >  5 files changed, 35 insertions(+), 13 deletions(-)
> > > > >  create mode 100755 scripts/pahole-flags.sh
> > > > >
> > > >
> > >
> >
>

  reply	other threads:[~2021-10-27 17:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-23 12:04 [RFC bpf-next 0/2] bpf: Fix BTF data for modules Jiri Olsa
2021-10-23 12:04 ` [PATCH bpf-next 1/2] kbuild: Unify options for BTF generation for vmlinux and modules Jiri Olsa
2021-10-26  4:56   ` Andrii Nakryiko
2021-10-26 12:03     ` Jiri Olsa
2021-10-23 12:04 ` [PATCH bpf-next 2/2] bpf: Add support to detect and dedup instances of same structs Jiri Olsa
2021-10-26  4:59   ` Andrii Nakryiko
2021-10-26  4:54 ` [RFC bpf-next 0/2] bpf: Fix BTF data for modules Andrii Nakryiko
2021-10-26 12:03   ` Jiri Olsa
2021-10-27  4:12     ` Andrii Nakryiko
2021-10-27  8:53       ` Jiri Olsa
2021-10-27 17:53         ` Andrii Nakryiko [this message]
2021-10-27 18:18           ` Jiri Olsa
2021-10-28 19:12             ` Jiri Olsa
2021-11-01 23:14               ` Andrii Nakryiko
2021-11-02 14:14                 ` Jiri Olsa
2021-11-07 14:57                   ` Jiri Olsa
2021-11-09 23:23                     ` Andrii Nakryiko
2021-11-12  7:23                       ` Jiri Olsa
2022-02-25 13:19                         ` Alexander Egorenkov
2022-02-25 17:15                           ` Jiri Olsa
2021-10-28  1:44           ` Kumar Kartikeya Dwivedi

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='CAEf4BzYP8eK0qxF+1UK7=TZ+vFRVMfmnm9AN=B2JHROoDwaHeg@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@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.