All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.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: Tue, 26 Oct 2021 14:03:34 +0200	[thread overview]
Message-ID: <YXfulitQY1+Gd35h@krava> (raw)
In-Reply-To: <CAEf4BzbaD60KFsUB4VkTAH2v3+GFkRvRbY_O-bNSpNG0=8pJ0Q@mail.gmail.com>

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

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-26 12:03 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 [this message]
2021-10-27  4:12     ` Andrii Nakryiko
2021-10-27  8:53       ` Jiri Olsa
2021-10-27 17:53         ` Andrii Nakryiko
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=YXfulitQY1+Gd35h@krava \
    --to=jolsa@redhat.com \
    --cc=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=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.