From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Kui-Feng Lee <sinquersw@gmail.com>
Cc: Alan Maguire <alan.maguire@oracle.com>,
yhs@fb.com, ast@kernel.org, olsajiri@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 dwarves 4/5] btf_encoder: represent "."-suffixed optimized functions (".isra.0") in BTF
Date: Wed, 25 Jan 2023 15:56:30 -0300 [thread overview]
Message-ID: <Y9F7Xt7Kt463kh6L@kernel.org> (raw)
In-Reply-To: <8b915c70-8ed4-9431-cd19-7e3194d29c09@gmail.com>
Em Wed, Jan 25, 2023 at 09:54:26AM -0800, Kui-Feng Lee escreveu:
>
> On 1/24/23 05:45, Alan Maguire wrote:
> > +/*
> > + * static functions with suffixes are not added yet - we need to
> > + * observe across all CUs to see if the static function has
> > + * optimized parameters in any CU, since in such a case it should
> > + * not be included in the final BTF. NF_HOOK.constprop.0() is
> > + * a case in point - it has optimized-out parameters in some CUs
> > + * but not others. In order to have consistency (since we do not
> > + * know which instance the BTF-specified function signature will
> > + * apply to), we simply skip adding functions which have optimized
> > + * out parameters anywhere.
> > + */
> > +static int32_t btf_encoder__save_func(struct btf_encoder *encoder, struct function *fn)
> > +{
> > + struct btf_encoder *parent = encoder->parent ? encoder->parent : encoder;
> > + const char *name = function__name(fn);
> > + struct function **nodep;
> > + int ret = 0;
> > +
> > + pthread_mutex_lock(&parent->saved_func_lock);
>
> Do you have the number of static functions with suffices?
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | grep '[[:alnum:]]\.' | wc -l
7245
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | wc -l
122336
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | grep '[[:alnum:]]\.constprop' | wc -l
1292
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | grep '[[:alnum:]]\.isra' | wc -l
1148
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | grep '[[:alnum:]]\.cold' | wc -l
4066
⬢[acme@toolbox linux]$ readelf -sW ../build/v6.2-rc5+/vmlinux | grep -w FUNC | grep '[[:alnum:]]\.part' | wc -l
1013
⬢[acme@toolbox linux]$
> If the number of static functions with suffices is high, the contention of
> the lock would be an issue.
>
> Is it possible to keep a local pool of static functions with suffices? The
> pool will be combined with its parent either at the completion of a CU,
> before ending the thread or when merging into the main thread.
May help, but I think maybe premature optimization is the root of... :-)
- Arnaldo
> > + nodep = tsearch(fn, &parent->saved_func_tree, function__compare);
> > + if (nodep == NULL) {
> > + fprintf(stderr, "error: out of memory adding local function '%s'\n",
> > + name);
> > + ret = -1;
> > + goto out;
> > + }
> > + /* If we find an existing entry, we want to merge observations
> > + * across both functions, checking that the "seen optimized-out
> > + * parameters" status is reflected in our tree entry.
> > + * If the entry is new, record encoder state required
> > + * to add the local function later (encoder + type_id_off)
> > + * such that we can add the function later.
> > + */
> > + if (*nodep != fn) {
> > + (*nodep)->proto.optimized_parms |= fn->proto.optimized_parms;
> > + } else {
> > + struct btf_encoder_state *state = zalloc(sizeof(*state));
> > +
> > + if (state == NULL) {
> > + fprintf(stderr, "error: out of memory adding local function '%s'\n",
> > + name);
> > + ret = -1;
> > + goto out;
> > + }
> > + state->encoder = encoder;
> > + state->type_id_off = encoder->type_id_off;
> > + fn->priv = state;
> > + encoder->saved_func_cnt++;
> > + if (encoder->verbose)
> > + printf("added local function '%s'%s\n", name,
> > + fn->proto.optimized_parms ?
> > + ", optimized-out params" : "");
> > + }
> > +out:
> > + pthread_mutex_unlock(&parent->saved_func_lock);
> > + return ret;
> > +}
> > +
--
- Arnaldo
next prev parent reply other threads:[~2023-01-25 18:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 13:45 [PATCH dwarves 0/5] dwarves: support encoding of optimized-out parameters, removal of inconsistent static functions Alan Maguire
2023-01-24 13:45 ` [PATCH dwarves 1/5] dwarves: help dwarf loader spot functions with optimized-out parameters Alan Maguire
2023-01-25 16:53 ` Jiri Olsa
2023-01-25 17:47 ` Eduard Zingerman
2023-01-25 18:28 ` Alan Maguire
2023-01-25 21:34 ` Eduard Zingerman
2023-01-25 22:52 ` Alan Maguire
2023-01-25 23:42 ` Eduard Zingerman
2023-01-26 0:20 ` Eduard Zingerman
2023-01-26 14:02 ` Alan Maguire
2023-01-26 15:02 ` Eduard Zingerman
2023-01-24 13:45 ` [PATCH dwarves 2/5] btf_encoder: refactor function addition into dedicated btf_encoder__add_func Alan Maguire
2023-01-24 13:45 ` [PATCH dwarves 3/5] btf_encoder: child encoders should have a reference to parent encoder Alan Maguire
2023-01-24 13:45 ` [PATCH dwarves 4/5] btf_encoder: represent "."-suffixed optimized functions (".isra.0") in BTF Alan Maguire
2023-01-25 17:54 ` Kui-Feng Lee
2023-01-25 18:56 ` Arnaldo Carvalho de Melo [this message]
2023-01-26 18:37 ` Kui-Feng Lee
2023-01-25 18:59 ` Alan Maguire
2023-01-26 17:43 ` Kui-Feng Lee
2023-01-24 13:45 ` [PATCH dwarves 5/5] btf_encoder: skip BTF encoding of static functions with inconsistent prototypes Alan Maguire
2023-01-25 13:39 ` Jiri Olsa
2023-01-25 14:18 ` Alan Maguire
2023-01-25 16:53 ` Jiri Olsa
2023-01-26 14:12 ` Alan Maguire
2023-01-24 15:14 ` [PATCH dwarves 0/5] dwarves: support encoding of optimized-out parameters, removal of inconsistent static functions Jiri Olsa
2023-01-24 16:11 ` Alan Maguire
2023-01-25 13:59 ` Jiri Olsa
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=Y9F7Xt7Kt463kh6L@kernel.org \
--to=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--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