From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alan Maguire <alan.maguire@oracle.com>,
yhs@fb.com, ast@kernel.org, olsajiri@gmail.com,
eddyz87@gmail.com, sinquersw@gmail.com, timo@incline.eu,
daniel@iogearbox.net, andrii@kernel.org, songliubraving@fb.com,
john.fastabend@gmail.com, kpsingh@chromium.org, sdf@google.com,
haoluo@google.com, martin.lau@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v2 dwarves 5/5] btf_encoder: delay function addition to check for function prototype inconsistencies
Date: Mon, 30 Jan 2023 15:08:49 -0300 [thread overview]
Message-ID: <Y9gHsXhe1ygOqI8t@kernel.org> (raw)
In-Reply-To: <20230130172037.vbe55faqcrkkxbge@macbook-pro-6.dhcp.thefacebook.com>
Em Mon, Jan 30, 2023 at 09:20:37AM -0800, Alexei Starovoitov escreveu:
> On Mon, Jan 30, 2023 at 02:29:45PM +0000, Alan Maguire wrote:
> > There are multiple sources of inconsistency that can result in
> > functions of the same name having multiple prototypes:
> >
> > - multiple static functions in different CUs share the same name
> > - static and external functions share the same name
> >
> > Here we attempt to catch such cases by finding inconsistencies
> > across CUs using the save/compare/merge mechanisms that were
> > previously introduced to handle optimized-out parameters,
> > using it for all functions.
> >
> > For two instances of a function to be considered consistent:
> >
> > - number of parameters must match
> > - parameter names must match
> >
> > The latter is a less strong method than a full type
> > comparison but suffices to match functions.
> >
> > With these changes, we see 278 functions removed due to
> > protoype inconsistency. For example, wakeup_show()
> > has two distinct prototypes:
> >
> > static ssize_t wakeup_show(struct kobject *kobj,
> > struct kobj_attribute *attr, char *buf)
> > (from kernel/irq/irqdesc.c)
> >
> > static ssize_t wakeup_show(struct device *dev, struct device_attribute *attr,
> > char *buf)
> > (from drivers/base/power/sysfs.c)
> >
> > In some other cases, the parameter comparisons weed out additional
> > inconsistencies in "."-suffixed functions across CUs.
> >
> > We also see a large number of functions eliminated due to
> > optimized-out parameters; 2542 functions are eliminated for this
> > reason, both "."-suffixed (1007) and otherwise (1535).
>
> imo it's a good thing.
>
> > Because the save/compare/merge process occurs for all functions
> > it is important to assess performance effects. In addition,
> > prior to these changes the number of functions ultimately
> > represented in BTF was non-deterministic when pahole was
> > run with multiple threads. This was due to the fact that
> > functions were marked as generated on a per-encoder basis
> > when first added, and as such the same function could
> > be added multiple times for different encoders, and if they
> > encountered inconsistent function prototypes, deduplication
> > could leave multiple entries in place for the same name.
> > When run in a single thread, the "generated" state associated
> > with the name would prevent this.
> >
> > Here we assess both BTF encoding performance and determinism
> > of the function representation in baseline compared to with
> > these changes. Determinism is assessed by counting the
> > number of functions in BTF. Comparisons are done for 1,
> > 4 and 8 threads.
> >
> > Baseline
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J vmlinux
> >
> > real 0m18.160s
> > user 0m17.179s
> > sys 0m0.757s
> >
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|wc -l
> > 51150
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|uniq|wc -l
> > 51150
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J -j4 vmlinux
> >
> > real 0m8.078s
> > user 0m17.978s
> > sys 0m0.732s
> >
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|wc -l
> > 51592
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|uniq|wc -l
> > 51150
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J -j8 vmlinux
> >
> > real 0m7.075s
> > user 0m19.010s
> > sys 0m0.587s
> >
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|wc -l
> > 51683
> > $ grep " FUNC " /tmp/vmlinux.btf.base |awk '{print $3}'|sort|uniq|wc -l
> > 51150
>
> Ouch. I didn't realize it is so random currently.
>
> > Test:
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J vmlinux
> >
> > real 0m19.039s
> > user 0m17.617s
> > sys 0m1.419s
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|wc -l
> > 49871
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|uniq|wc -l
> > 49871
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J -j4 vmlinux
> >
> > real 0m8.482s
> > user 0m18.233s
> > sys 0m2.412s
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|wc -l
> > 49871
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|uniq|wc -l
> > 49871
> >
> > $ time LLVM_OBJCOPY=objcopy pahole -J -j8 vmlinux
> >
> > real 0m7.614s
> > user 0m19.384s
> > sys 0m3.739s
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|wc -l
> > 49871
> > $ bpftool btf dump file vmlinux | grep ' FUNC ' |sort|uniq|wc -l
> >
> > So there is a small cost in performance, but we improve determinism
> > and the consistency of representation.
>
> This is a great fix.
>
> I'm not an expert in this code base, but patches look good to me.
> Thank you for fixing it.
And all the description of the problem and of the solution, limitations,
together with a summary of the review comments, its a pleasure to
process a patch series like this one :-)
Doing that now and performing the usual tests,
Thanks,
- Arnaldo
> > For now it is better to have an incomplete representation
> > that more accurately reflects the actual function parameters
> > used, removing inconsistencies that could otherwise do harm.
>
> +1
--
- Arnaldo
prev parent reply other threads:[~2023-01-30 18:09 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-30 14:29 [PATCH v2 dwarves 0/5] dwarves: support encoding of optimized-out parameters, removal of inconsistent static functions Alan Maguire
2023-01-30 14:29 ` [PATCH v2 dwarves 1/5] dwarves: help dwarf loader spot functions with optimized-out parameters Alan Maguire
2023-01-30 18:36 ` Arnaldo Carvalho de Melo
2023-01-30 20:10 ` Arnaldo Carvalho de Melo
2023-01-30 20:23 ` Arnaldo Carvalho de Melo
2023-01-30 22:37 ` Alan Maguire
2023-01-31 0:25 ` Arnaldo Carvalho de Melo
2023-01-31 1:04 ` Arnaldo Carvalho de Melo
2023-01-31 12:14 ` Alan Maguire
2023-01-31 12:33 ` Arnaldo Carvalho de Melo
2023-01-31 13:35 ` Jiri Olsa
2023-01-31 17:43 ` Alexei Starovoitov
2023-01-31 18:16 ` Alexei Starovoitov
2023-01-31 23:45 ` Alan Maguire
2023-01-31 23:58 ` David Vernet
2023-02-01 0:14 ` Alexei Starovoitov
2023-02-01 3:02 ` David Vernet
2023-02-01 13:59 ` Alan Maguire
2023-02-01 15:02 ` Arnaldo Carvalho de Melo
2023-02-01 15:13 ` Alan Maguire
2023-02-01 15:19 ` David Vernet
2023-02-01 16:49 ` Alexei Starovoitov
2023-02-01 17:01 ` Arnaldo Carvalho de Melo
2023-02-01 17:18 ` Alan Maguire
2023-02-01 18:54 ` Arnaldo Carvalho de Melo
2023-02-01 22:33 ` Alan Maguire
2023-02-01 22:32 ` Arnaldo Carvalho de Melo
2023-02-02 1:09 ` Arnaldo Carvalho de Melo
2023-02-03 1:09 ` Yonghong Song
2023-01-30 14:29 ` [PATCH v2 dwarves 2/5] btf_encoder: refactor function addition into dedicated btf_encoder__add_func Alan Maguire
2023-02-01 17:19 ` Arnaldo Carvalho de Melo
2023-02-01 17:50 ` Alan Maguire
2023-02-01 18:59 ` Arnaldo Carvalho de Melo
2023-01-30 14:29 ` [PATCH v2 dwarves 3/5] btf_encoder: rework btf_encoders__*() API to allow traversal of encoders Alan Maguire
2023-01-30 22:04 ` Jiri Olsa
2023-01-31 0:24 ` Arnaldo Carvalho de Melo
2023-01-30 14:29 ` [PATCH v2 dwarves 4/5] btf_encoder: represent "."-suffixed functions (".isra.0") in BTF Alan Maguire
2023-01-30 14:29 ` [PATCH v2 dwarves 5/5] btf_encoder: delay function addition to check for function prototype inconsistencies Alan Maguire
2023-01-30 17:20 ` Alexei Starovoitov
2023-01-30 18:08 ` Arnaldo Carvalho de Melo [this message]
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=Y9gHsXhe1ygOqI8t@kernel.org \
--to=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@chromium.org \
--cc=martin.lau@kernel.org \
--cc=olsajiri@gmail.com \
--cc=sdf@google.com \
--cc=sinquersw@gmail.com \
--cc=songliubraving@fb.com \
--cc=timo@incline.eu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox