All of lore.kernel.org
 help / color / mirror / Atom feed
From: Puranjay Mohan <puranjay12@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, catalin.marinas@arm.com,
	mark.rutland@arm.com, bpf@vger.kernel.org, kpsingh@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Björn Töpel" <bjorn@kernel.org>
Subject: Re: [PATCH bpf-next v4 3/3] bpf, arm64: use bpf_jit_binary_pack_alloc
Date: Tue, 15 Aug 2023 16:09:36 +0200	[thread overview]
Message-ID: <CANk7y0gcP3dF2mESLp5JN1+9iDfgtiWRFGqLkCgZD6wby1kQOw@mail.gmail.com> (raw)
In-Reply-To: <20230626085811.3192402-4-puranjay12@gmail.com>

Hi Everyone,

[+cc Björn]

On Mon, Jun 26, 2023 at 10:58 AM Puranjay Mohan <puranjay12@gmail.com> wrote:
>
> Use bpf_jit_binary_pack_alloc for memory management of JIT binaries in
> ARM64 BPF JIT. The bpf_jit_binary_pack_alloc creates a pair of RW and RX
> buffers. The JIT writes the program into the RW buffer. When the JIT is
> done, the program is copied to the final RX buffer
> with bpf_jit_binary_pack_finalize.
>
> Implement bpf_arch_text_copy() and bpf_arch_text_invalidate() for ARM64
> JIT as these functions are required by bpf_jit_binary_pack allocator.
>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> Acked-by: Song Liu <song@kernel.org>

[...]

> +int bpf_arch_text_invalidate(void *dst, size_t len)
> +{
> +       __le32 *ptr;
> +       int ret;
> +
> +       for (ptr = dst; len >= sizeof(u32); len -= sizeof(u32)) {
> +               ret = aarch64_insn_patch_text_nosync(ptr++, AARCH64_BREAK_FAULT);
> +               if (ret)
> +                       return ret;
> +       }
> +
> +       return 0;
> +}
> +

While testing the same patch for riscv bpf jit, Björn found that
./test_tag is taking a lot of
time to complete. He found that bpf_arch_text_invalidate() is calling
patch_text_nosync() in RISCV
and aarch64_insn_patch_text_nosync() here in ARM64. Both of the
implementations call these functions
in a loop for each word. The problem is that every call to
patch_text_nosync()/aarch64_insn_patch_text_nosync()
would clean the cache. This will make this
function(bpf_arch_text_invalidate) really slow.

I did some testing using the vmtest.sh script on ARM64 with and
without the patches, here are the results:

With Prog Pack patches applied:
=========================

root@(none):/# time ./root/bpf/test_tag
test_tag: OK (40945 tests)

real    3m2.001s
user    0m1.644s
sys     2m40.132s

Without Prog Pack:
===============

root@(none):/# time ./root/bpf/test_tag
test_tag: OK (40945 tests)

real    0m26.809s
user    0m1.591s
sys     0m24.106s

As you can see the current implementation of
bpf_arch_text_invalidate() is really slow. I need to
implement a new function: aarch64_insn_set_text_nosync() and use it in
bpf_arch_text_invalidate()
rather than calling aarch64_insn_patch_text_nosync() in a loop.

In the longer run, it would be really helpful if we have a standard
text_poke API like x86 in every architecture.

Thanks,
Puranjay

WARNING: multiple messages have this Message-ID (diff)
From: Puranjay Mohan <puranjay12@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, catalin.marinas@arm.com,
	mark.rutland@arm.com, bpf@vger.kernel.org, kpsingh@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Björn Töpel" <bjorn@kernel.org>
Subject: Re: [PATCH bpf-next v4 3/3] bpf, arm64: use bpf_jit_binary_pack_alloc
Date: Tue, 15 Aug 2023 16:09:36 +0200	[thread overview]
Message-ID: <CANk7y0gcP3dF2mESLp5JN1+9iDfgtiWRFGqLkCgZD6wby1kQOw@mail.gmail.com> (raw)
In-Reply-To: <20230626085811.3192402-4-puranjay12@gmail.com>

Hi Everyone,

[+cc Björn]

On Mon, Jun 26, 2023 at 10:58 AM Puranjay Mohan <puranjay12@gmail.com> wrote:
>
> Use bpf_jit_binary_pack_alloc for memory management of JIT binaries in
> ARM64 BPF JIT. The bpf_jit_binary_pack_alloc creates a pair of RW and RX
> buffers. The JIT writes the program into the RW buffer. When the JIT is
> done, the program is copied to the final RX buffer
> with bpf_jit_binary_pack_finalize.
>
> Implement bpf_arch_text_copy() and bpf_arch_text_invalidate() for ARM64
> JIT as these functions are required by bpf_jit_binary_pack allocator.
>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
> Acked-by: Song Liu <song@kernel.org>

[...]

> +int bpf_arch_text_invalidate(void *dst, size_t len)
> +{
> +       __le32 *ptr;
> +       int ret;
> +
> +       for (ptr = dst; len >= sizeof(u32); len -= sizeof(u32)) {
> +               ret = aarch64_insn_patch_text_nosync(ptr++, AARCH64_BREAK_FAULT);
> +               if (ret)
> +                       return ret;
> +       }
> +
> +       return 0;
> +}
> +

While testing the same patch for riscv bpf jit, Björn found that
./test_tag is taking a lot of
time to complete. He found that bpf_arch_text_invalidate() is calling
patch_text_nosync() in RISCV
and aarch64_insn_patch_text_nosync() here in ARM64. Both of the
implementations call these functions
in a loop for each word. The problem is that every call to
patch_text_nosync()/aarch64_insn_patch_text_nosync()
would clean the cache. This will make this
function(bpf_arch_text_invalidate) really slow.

I did some testing using the vmtest.sh script on ARM64 with and
without the patches, here are the results:

With Prog Pack patches applied:
=========================

root@(none):/# time ./root/bpf/test_tag
test_tag: OK (40945 tests)

real    3m2.001s
user    0m1.644s
sys     2m40.132s

Without Prog Pack:
===============

root@(none):/# time ./root/bpf/test_tag
test_tag: OK (40945 tests)

real    0m26.809s
user    0m1.591s
sys     0m24.106s

As you can see the current implementation of
bpf_arch_text_invalidate() is really slow. I need to
implement a new function: aarch64_insn_set_text_nosync() and use it in
bpf_arch_text_invalidate()
rather than calling aarch64_insn_patch_text_nosync() in a loop.

In the longer run, it would be really helpful if we have a standard
text_poke API like x86 in every architecture.

Thanks,
Puranjay

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-15 14:10 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26  8:58 [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT Puranjay Mohan
2023-06-26  8:58 ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 1/3] bpf: make bpf_prog_pack allocator portable Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 2/3] arm64: patching: Add aarch64_insn_copy() Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-06-26  8:58 ` [PATCH bpf-next v4 3/3] bpf, arm64: use bpf_jit_binary_pack_alloc Puranjay Mohan
2023-06-26  8:58   ` Puranjay Mohan
2023-08-15 14:09   ` Puranjay Mohan [this message]
2023-08-15 14:09     ` Puranjay Mohan
2023-08-16 13:25     ` Daniel Borkmann
2023-08-16 13:25       ` Daniel Borkmann
2023-06-30 17:20 ` [PATCH bpf-next v4 0/3] bpf, arm64: use BPF prog pack allocator in BPF JIT Florent Revest
2023-06-30 17:20   ` Florent Revest
2023-07-03 16:40 ` Daniel Borkmann
2023-07-03 16:40   ` Daniel Borkmann
2023-07-03 17:15   ` Mark Rutland
2023-07-03 17:15     ` Mark Rutland
2023-07-03 17:54     ` Daniel Borkmann
2023-07-03 17:54       ` Daniel Borkmann
2023-07-17  7:50     ` Puranjay Mohan
2023-07-17  7:50       ` Puranjay Mohan
2023-07-30 17:22       ` Puranjay Mohan
2023-07-30 17:22         ` Puranjay Mohan
2023-08-02 21:02         ` Alexei Starovoitov
2023-08-02 21:02           ` Alexei Starovoitov
2023-08-03 11:13           ` Mark Rutland
2023-08-03 11:13             ` Mark Rutland
2023-08-03 16:15             ` Alexei Starovoitov
2023-08-03 16:15               ` Alexei Starovoitov
2023-08-03 16:32               ` Florent Revest
2023-08-03 16:32                 ` Florent Revest
2023-08-04 15:11             ` Puranjay Mohan
2023-08-04 15:11               ` Puranjay Mohan
2023-11-02 15:59             ` Mark Rutland
2023-11-02 15:59               ` Mark Rutland

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=CANk7y0gcP3dF2mESLp5JN1+9iDfgtiWRFGqLkCgZD6wby1kQOw@mail.gmail.com \
    --to=puranjay12@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=song@kernel.org \
    /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.