All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Jiri Olsa" <olsajiri@gmail.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>, <bpf@vger.kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"Mike Rapoport" <rppt@kernel.org>
Subject: Re: [PATCHv2 bpf-next 3/3] bpf, x86: Add support for jit dry run
Date: Fri, 04 Sep 2026 07:55:02 -0700	[thread overview]
Message-ID: <DL6MA7Z7QSI9.1DOEM4TWTJN5B@gmail.com> (raw)
In-Reply-To: <app3IQUwVF97Tfq1@krava>

On Fri Sep 4, 2026 at 12:45 AM PDT, Jiri Olsa wrote:
> On Thu, Sep 03, 2026 at 09:40:46PM -0700, Alexei Starovoitov wrote:
>> On Thu Sep 3, 2026 at 2:20 AM PDT, Jiri Olsa wrote:
>> > Adding support to run jit code generation in dry_run mode that won't
>> > store any code and only returns the jir code size.
>> >
>> > The dry_run is enabled when __arch_prepare_bpf_trampoline is called
>> > with rw_image argument as NULL.
>> >
>> > It's used in arch_bpf_trampoline_size where it allows to skip the
>> > image allocation, that gives speed up for tracing_multi attachment.
>> >
>> > With current code:
>> >
>> >   # ./test_progs -t tracing_multi_bench_attach -v
>> >   ...
>> >   serial_test_tracing_multi_bench_attach: found 55227 functions
>> >   serial_test_tracing_multi_bench_attach: attached in   1.563s
>> >   serial_test_tracing_multi_bench_attach: detached in   0.256s
>> >
>> > With the fix:
>> >
>> >   # ./test_progs -t tracing_multi_bench_attach -v
>> >   ...
>> >   serial_test_tracing_multi_bench_attach: found 55235 functions
>> >   serial_test_tracing_multi_bench_attach: attached in   0.798s
>> >   serial_test_tracing_multi_bench_attach: detached in   0.258s
>> >
>> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>> > ---
>> >  arch/x86/net/bpf_jit_comp.c | 42 ++++++++++++++++++-------------------
>> >  1 file changed, 20 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> > index ee2ddeba3de1..d1af7dc5c5ce 100644
>> > --- a/arch/x86/net/bpf_jit_comp.c
>> > +++ b/arch/x86/net/bpf_jit_comp.c
>> > @@ -25,6 +25,7 @@ static bool all_callee_regs_used[4] = {true, true, true, true};
>> >  
>> >  struct jit_emit_context {
>> >  	u8 *prog;
>> > +	bool dry_run;
>> >  };
>> >  
>> >  static u8 *emit_code(u8 *ptr, u32 bytes, unsigned int len)
>> > @@ -42,7 +43,10 @@ static u8 *emit_code(u8 *ptr, u32 bytes, unsigned int len)
>> >  
>> >  static void emit_code_jit(struct jit_emit_context *jit, u32 bytes, unsigned int len)
>> >  {
>> > -	jit->prog = emit_code(jit->prog, bytes, len);
>> > +	if (jit->dry_run)
>> > +		jit->prog += len;
>> > +	else
>> > +		jit->prog = emit_code(jit->prog, bytes, len);
>> 
>> Sorry, I don't believe that skipping emit makes that much
>> of runtime difference.
>> I suspect jit_alloc + jit_free are costly.
>> In such case the earlier patches are not needed.
>> Point emit logic to some scratch area and discard it.
>> Same effect with half of the changes.
>> 
>> pw-bot: cr
>> 
>
> yes, I got same speed up with the change below

Great :)

> jirka
>
>
> ---
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 48429fae0641..1bba19a9a17f 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -9,6 +9,7 @@
>  #include <linux/filter.h>
>  #include <linux/if_vlan.h>
>  #include <linux/bitfield.h>
> +#include <linux/init.h>
>  #include <linux/bpf.h>
>  #include <linux/bpf_verifier.h>
>  #include <linux/memory.h>
> @@ -23,6 +24,19 @@
>  
>  static bool all_callee_regs_used[4] = {true, true, true, true};
>  
> +/*
> + * Reuse a writable image in the BPF execmem range for size calculation.
> + * Its contents do not affect size calculation.
> + */
> +static void *trampoline_size_image;
> +
> +static int __init init_trampoline_size_image(void)
> +{
> +	trampoline_size_image = bpf_jit_alloc_exec_rw(PAGE_SIZE);

I think you could have kvmalloc()-ed that memory instead.

> +	return trampoline_size_image ? 0 : -ENOMEM;
> +}
> +late_initcall(init_trampoline_size_image);
> +
>  static u8 *emit_code(u8 *ptr, u32 bytes, unsigned int len)
>  {
>  	if (len == 1)
> @@ -3819,23 +3833,14 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags,
>  			     struct bpf_tramp_nodes *tnodes, void *func_addr)
>  {
>  	struct bpf_tramp_image im;
> -	void *image;
> -	int ret;
>  
> -	/* Allocate a temporary buffer for __arch_prepare_bpf_trampoline().
> -	 *
> -	 * We cannot use kvmalloc here, because we need image to be in
> -	 * module memory range.
> -	 * Since it must be writable use bpf_jit_alloc_exec_rw().
> -	 */
> -	image = bpf_jit_alloc_exec_rw(PAGE_SIZE);
> -	if (!image)
> +	if (!trampoline_size_image)
>  		return -ENOMEM;
>  
> -	ret = __arch_prepare_bpf_trampoline(&im, image, image + PAGE_SIZE, image,
> -					    m, flags, tnodes, func_addr);
> -	bpf_jit_free_exec(image);
> -	return ret;
> +	return __arch_prepare_bpf_trampoline(&im, trampoline_size_image,
> +					     trampoline_size_image + PAGE_SIZE,
> +					     trampoline_size_image, m, flags,
> +					     tnodes, func_addr);
>  }
>  
>  static int emit_bpf_dispatcher(u8 **pprog, int a, int b, s64 *progs, u8 *image, u8 *buf)


      reply	other threads:[~2026-09-04 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03  9:20 [PATCHv2 bpf-next 0/3] bpf, x86: Add jit dry run mode Jiri Olsa
2026-09-03  9:20 ` [PATCHv2 bpf-next 1/3] bpf, x86: Split x86_call_depth_emit_accounting in two functions Jiri Olsa
2026-09-03 10:14   ` bot+bpf-ci
2026-09-03  9:20 ` [PATCHv2 bpf-next 2/3] bpf, x86: Introduce JIT emission context Jiri Olsa
2026-09-03 10:14   ` bot+bpf-ci
2026-09-03  9:20 ` [PATCHv2 bpf-next 3/3] bpf, x86: Add support for jit dry run Jiri Olsa
2026-09-03 10:28   ` bot+bpf-ci
2026-09-04  4:40   ` Alexei Starovoitov
2026-09-04  7:45     ` Jiri Olsa
2026-09-04 14:55       ` Alexei Starovoitov [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=DL6MA7Z7QSI9.1DOEM4TWTJN5B@gmail.com \
    --to=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=martin.lau@linux.dev \
    --cc=olsajiri@gmail.com \
    --cc=rppt@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 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.