From: Jiri Olsa <olsajiri@gmail.com>
To: Rong Tao <rtoax@foxmail.com>
Cc: sdf@google.com, daniel@iogearbox.net, andrii@kernel.org,
rongtao@cestc.cn, Alexei Starovoitov <ast@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
"open list:BPF [GENERAL] (Safe Dynamic Programs and Tools)"
<bpf@vger.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v5] selftests/bpf: trace_helpers.c: optimize kallsyms cache
Date: Thu, 17 Aug 2023 10:21:15 +0200 [thread overview]
Message-ID: <ZN3YeyMkgEg1IoKP@krava> (raw)
In-Reply-To: <tencent_0E9E1A1C0981678D5E7EA9E4BDBA8EE2200A@qq.com>
On Thu, Aug 17, 2023 at 01:03:45PM +0800, Rong Tao wrote:
> From: Rong Tao <rongtao@cestc.cn>
>
> Static ksyms often have problems because the number of symbols exceeds the
> MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in
> commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves
> the problem somewhat, but it's not the perfect way.
>
> This commit uses dynamic memory allocation, which completely solves the
> problem caused by the limitation of the number of kallsyms.
>
> Acked-by: Stanislav Fomichev <sdf@google.com>
> Signed-off-by: Rong Tao <rongtao@cestc.cn>
> ---
> v5: Release the allocated memory once the load_kallsyms_refresh() upon error
> given it's dynamically allocated.
> v4: https://lore.kernel.org/lkml/tencent_59C74613113F0C728524B2A82FE5540A5E09@qq.com/
> Make sure most cases we don't need the realloc() path to begin with,
> and check strdup() return value.
> v3: https://lore.kernel.org/lkml/tencent_50B4B2622FE7546A5FF9464310650C008509@qq.com/
> Do not use structs and judge ksyms__add_symbol function return value.
> v2: https://lore.kernel.org/lkml/tencent_B655EE5E5D463110D70CD2846AB3262EED09@qq.com/
> Do the usual len/capacity scheme here to amortize the cost of realloc, and
> don't free symbols.
> v1: https://lore.kernel.org/lkml/tencent_AB461510B10CD484E0B2F62E3754165F2909@qq.com/
> ---
> tools/testing/selftests/bpf/trace_helpers.c | 62 +++++++++++++++++----
> 1 file changed, 52 insertions(+), 10 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c
> index f83d9f65c65b..0053ba22f0cb 100644
> --- a/tools/testing/selftests/bpf/trace_helpers.c
> +++ b/tools/testing/selftests/bpf/trace_helpers.c
> @@ -18,10 +18,47 @@
> #define TRACEFS_PIPE "/sys/kernel/tracing/trace_pipe"
> #define DEBUGFS_PIPE "/sys/kernel/debug/tracing/trace_pipe"
>
> -#define MAX_SYMS 400000
> -static struct ksym syms[MAX_SYMS];
> +static struct ksym *syms;
> +static int sym_cap;
> static int sym_cnt;
>
> +static int ksyms__add_symbol(const char *name, unsigned long addr)
> +{
> + void *tmp;
> + unsigned int new_cap;
> +
> + if (sym_cnt + 1 > sym_cap) {
> + new_cap = sym_cap * 4 / 3;
> + tmp = realloc(syms, sizeof(struct ksym) * new_cap);
> + if (!tmp)
> + return -ENOMEM;
> + syms = tmp;
> + sym_cap = new_cap;
> + }
sorry I did not notice earlier, but we have helper for realloc
libbpf_ensure_mem
check the usage for example in prog_tests/kprobe_multi_test.c
> +
> + tmp = strdup(name);
> + if (!tmp)
> + return -ENOMEM;
> + syms[sym_cnt].addr = addr;
> + syms[sym_cnt].name = tmp;
> +
> + sym_cnt++;
> +
> + return 0;
> +}
> +
> +static void ksyms__free(void)
> +{
> + unsigned int i;
> +
> + if (!syms)
> + return;
> +
> + for (i = 0; i < sym_cnt; i++)
> + free(syms[i].name);
> + free(syms);
> +}
> +
> static int ksym_cmp(const void *p1, const void *p2)
> {
> return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr;
> @@ -33,9 +70,14 @@ int load_kallsyms_refresh(void)
> char func[256], buf[256];
> char symbol;
> void *addr;
> - int i = 0;
> + int ret;
>
> + /* Make sure most cases we don't need the realloc() path to begin with */
> + sym_cap = 400000;
> sym_cnt = 0;
> + syms = malloc(sizeof(struct ksym) * sym_cap);
> + if (!syms)
> + return -ENOMEM;
libbpf_ensure_mem will also take care of first allocation and the capacity increase
jirka
>
> f = fopen("/proc/kallsyms", "r");
> if (!f)
> @@ -46,17 +88,17 @@ int load_kallsyms_refresh(void)
> break;
> if (!addr)
> continue;
> - if (i >= MAX_SYMS)
> - return -EFBIG;
> -
> - syms[i].addr = (long) addr;
> - syms[i].name = strdup(func);
> - i++;
> + ret = ksyms__add_symbol(func, (unsigned long)addr);
> + if (ret)
> + goto error;
> }
> fclose(f);
> - sym_cnt = i;
> qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp);
> return 0;
> +
> +error:
> + ksyms__free();
> + return ret;
> }
>
> int load_kallsyms(void)
> --
> 2.39.3
>
>
next prev parent reply other threads:[~2023-08-17 8:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 5:03 [PATCH bpf-next v5] selftests/bpf: trace_helpers.c: optimize kallsyms cache Rong Tao
2023-08-17 8:21 ` Jiri Olsa [this message]
2023-08-18 1:39 ` Rong Tao
2023-08-18 12:20 ` Jiri Olsa
2023-08-18 15:36 ` Rong Tao
2023-08-18 17:50 ` Yonghong Song
2023-08-21 2:03 ` Rong Tao
2023-08-21 4:34 ` Yonghong Song
2023-08-21 6:49 ` Rong Tao
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=ZN3YeyMkgEg1IoKP@krava \
--to=olsajiri@gmail.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@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=rongtao@cestc.cn \
--cc=rtoax@foxmail.com \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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