BPF programs currently consume a page each on ARM64. For systems with many BPF
programs, this adds significant pressure to instruction TLB. High iTLB pressure
usually causes slow down for the whole system.
Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
It packs multiple BPF programs into a single huge page. It is currently only
enabled for the x86_64 BPF JIT.
This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
====================================================
Performance Analysis of prog pack allocator on ARM64
====================================================
To test the performance of the BPF prog pack allocator on ARM64, a stresser
tool[2] was built. This tool loads 8 BPF programs on the system and triggers
5 of them in an infinite loop by doing system calls.
The runner script starts 20 instances of the above which loads 8*20=160 BPF
programs on the system, 5*20=100 of which are being constantly triggered.
In the above environment we try to build Python-3.8.4 and try to find different
iTLB metrics for the compilation done by gcc-12.2.0.
The source code[3] is configured with the following command:
./configure --enable-optimizations --with-ensurepip=install
Then the runner script is executed with the following command:
./run.sh "perf stat -e ITLB_WALK,L1I_TLB,INST_RETIRED,iTLB-load-misses -a make -j32"
This builds Python while 160 BPF programs are loaded and 100 are being constantly
triggered and measures iTLB related metrics.
The output of the above command is discussed below before and after enabling the
BPF prog pack allocator.
The tests were run on qemu-system-aarch64 with 32 cpus, 4G memory, -machine virt,
-cpu host, and -enable-kvm.
Results
-------
Before enabling prog pack allocator:
------------------------------------
Performance counter stats for 'system wide':
333278635 ITLB_WALK
6762692976558 L1I_TLB
25359571423901 INST_RETIRED
15824054789 iTLB-load-misses
189.029769053 seconds time elapsed
After enabling prog pack allocator:
-----------------------------------
Performance counter stats for 'system wide':
190333544 ITLB_WALK
6712712386528 L1I_TLB
25278233304411 INST_RETIRED
5716757866 iTLB-load-misses
185.392650561 seconds time elapsed
Improvements in metrics
-----------------------
Compilation time ---> 1.92% faster
iTLB-load-misses/Sec (Less is better) ---> 63.16% decrease
ITLB_WALK/1000 INST_RETIRED (Less is better) ---> 42.71% decrease
ITLB_Walk/L1I_TLB (Less is better) ---> 42.47% decrease
[1] https://lore.kernel.org/bpf/[email protected]/
[2] https://github.com/puranjaymohan/BPF-Allocator-Bench
[3] https://www.python.org/ftp/python/3.8.4/Python-3.8.4.tgz
Chanes in V3 => V4: Changes only in 3rd patch
1. Fix the I-cache maintenance: Clean the data cache and invalidate the i-Cache
only *after* the instructions have been copied to the ROX region.
Chanes in V2 => V3: Changes only in 3rd patch
1. Set prog = orig_prog; in the failure path of bpf_jit_binary_pack_finalize()
call.
2. Add comments explaining the usage of the offsets in the exception table.
Changes in v1 => v2:
1. Make the naming consistent in the 3rd patch:
ro_image and image
ro_header and header
ro_image_ptr and image_ptr
2. Use names dst/src in place of addr/opcode in second patch.
3. Add Acked-by: Song Liu <[email protected]> in 1st and 2nd patch.
Puranjay Mohan (3):
bpf: make bpf_prog_pack allocator portable
arm64: patching: Add aarch64_insn_copy()
bpf, arm64: use bpf_jit_binary_pack_alloc
arch/arm64/include/asm/patching.h | 1 +
arch/arm64/kernel/patching.c | 39 ++++++++
arch/arm64/net/bpf_jit_comp.c | 145 +++++++++++++++++++++++++-----
kernel/bpf/core.c | 8 +-
4 files changed, 165 insertions(+), 28 deletions(-)
--
2.40.1
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 <[email protected]>
Acked-by: Song Liu <[email protected]>
---
Changes in v3 => v4:
- Fix the cache maintenance by cleaning the data cache and invalidating the
i-Cache only *after* copying the instructions to the ROX region.
Changes in v2 => v3:
- Set prog = orig_prog; in the failure path of bpf_jit_binary_pack_finalize()
call.
- Add comments explaining the usage of the offsets in the exception table.
Changes in v1 => v2:
- Made the naming of ro_ prefix consistent.
Now image/header/image_ptr are read/write and
ro_image/ro_header/ro_image_ptr are read-only.
arch/arm64/net/bpf_jit_comp.c | 145 ++++++++++++++++++++++++++++------
1 file changed, 121 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 145b540ec34f..cd05f0c513f4 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -76,6 +76,7 @@ struct jit_ctx {
int *offset;
int exentry_idx;
__le32 *image;
+ __le32 *ro_image;
u32 stack_size;
int fpb_offset;
};
@@ -205,6 +206,20 @@ static void jit_fill_hole(void *area, unsigned int size)
*ptr++ = cpu_to_le32(AARCH64_BREAK_FAULT);
}
+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;
+}
+
static inline int epilogue_offset(const struct jit_ctx *ctx)
{
int to = ctx->epilogue_offset;
@@ -701,7 +716,8 @@ static int add_exception_handler(const struct bpf_insn *insn,
struct jit_ctx *ctx,
int dst_reg)
{
- off_t offset;
+ off_t ins_offset;
+ off_t fixup_offset;
unsigned long pc;
struct exception_table_entry *ex;
@@ -717,12 +733,17 @@ static int add_exception_handler(const struct bpf_insn *insn,
return -EINVAL;
ex = &ctx->prog->aux->extable[ctx->exentry_idx];
- pc = (unsigned long)&ctx->image[ctx->idx - 1];
+ pc = (unsigned long)&ctx->ro_image[ctx->idx - 1];
- offset = pc - (long)&ex->insn;
- if (WARN_ON_ONCE(offset >= 0 || offset < INT_MIN))
+ /*
+ * This is the relative offset of the instruction that may fault from
+ * the exception table itself. This will be written to the exception
+ * table and if this instruction faults, the destination register will
+ * be set to '0' and the execution will jump to the next instruction.
+ */
+ ins_offset = pc - (long)&ex->insn;
+ if (WARN_ON_ONCE(ins_offset >= 0 || ins_offset < INT_MIN))
return -ERANGE;
- ex->insn = offset;
/*
* Since the extable follows the program, the fixup offset is always
@@ -731,12 +752,25 @@ static int add_exception_handler(const struct bpf_insn *insn,
* bits. We don't need to worry about buildtime or runtime sort
* modifying the upper bits because the table is already sorted, and
* isn't part of the main exception table.
+ *
+ * The fixup_offset is set to the next instruction from the instruction
+ * that may fault. The execution will jump to this after handling the
+ * fault.
*/
- offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE);
- if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, offset))
+ fixup_offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE);
+ if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, fixup_offset))
return -ERANGE;
- ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, offset) |
+ /*
+ * The offsets above have been calculated using the RO buffer but we
+ * need to use the R/W buffer for writes.
+ * switch ex to rw buffer for writing.
+ */
+ ex = (void *)ctx->image + ((void *)ex - (void *)ctx->ro_image);
+
+ ex->insn = ins_offset;
+
+ ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, fixup_offset) |
FIELD_PREP(BPF_FIXUP_REG_MASK, dst_reg);
ex->type = EX_TYPE_BPF;
@@ -1446,7 +1480,8 @@ static inline void bpf_flush_icache(void *start, void *end)
struct arm64_jit_data {
struct bpf_binary_header *header;
- u8 *image;
+ u8 *ro_image;
+ struct bpf_binary_header *ro_header;
struct jit_ctx ctx;
};
@@ -1455,12 +1490,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
int image_size, prog_size, extable_size, extable_align, extable_offset;
struct bpf_prog *tmp, *orig_prog = prog;
struct bpf_binary_header *header;
+ struct bpf_binary_header *ro_header;
struct arm64_jit_data *jit_data;
bool was_classic = bpf_prog_was_classic(prog);
bool tmp_blinded = false;
bool extra_pass = false;
struct jit_ctx ctx;
u8 *image_ptr;
+ u8 *ro_image_ptr;
if (!prog->jit_requested)
return orig_prog;
@@ -1487,8 +1524,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
}
if (jit_data->ctx.offset) {
ctx = jit_data->ctx;
- image_ptr = jit_data->image;
+ ro_image_ptr = jit_data->ro_image;
+ ro_header = jit_data->ro_header;
header = jit_data->header;
+ image_ptr = (void *)header + ((void *)ro_image_ptr
+ - (void *)ro_header);
extra_pass = true;
prog_size = sizeof(u32) * ctx.idx;
goto skip_init_ctx;
@@ -1533,18 +1573,27 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
/* also allocate space for plt target */
extable_offset = round_up(prog_size + PLT_TARGET_SIZE, extable_align);
image_size = extable_offset + extable_size;
- header = bpf_jit_binary_alloc(image_size, &image_ptr,
- sizeof(u32), jit_fill_hole);
- if (header == NULL) {
+ ro_header = bpf_jit_binary_pack_alloc(image_size, &ro_image_ptr,
+ sizeof(u32), &header, &image_ptr,
+ jit_fill_hole);
+ if (!ro_header) {
prog = orig_prog;
goto out_off;
}
/* 2. Now, the actual pass. */
+ /*
+ * Use the image(RW) for writing the JITed instructions. But also save
+ * the ro_image(RX) for calculating the offsets in the image. The RW
+ * image will be later copied to the RX image from where the program
+ * will run. The bpf_jit_binary_pack_finalize() will do this copy in the
+ * final step.
+ */
ctx.image = (__le32 *)image_ptr;
+ ctx.ro_image = (__le32 *)ro_image_ptr;
if (extable_size)
- prog->aux->extable = (void *)image_ptr + extable_offset;
+ prog->aux->extable = (void *)ro_image_ptr + extable_offset;
skip_init_ctx:
ctx.idx = 0;
ctx.exentry_idx = 0;
@@ -1552,9 +1601,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
build_prologue(&ctx, was_classic);
if (build_body(&ctx, extra_pass)) {
- bpf_jit_binary_free(header);
prog = orig_prog;
- goto out_off;
+ goto out_free_hdr;
}
build_epilogue(&ctx);
@@ -1562,34 +1610,44 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
/* 3. Extra pass to validate JITed code. */
if (validate_ctx(&ctx)) {
- bpf_jit_binary_free(header);
prog = orig_prog;
- goto out_off;
+ goto out_free_hdr;
}
/* And we're done. */
if (bpf_jit_enable > 1)
bpf_jit_dump(prog->len, prog_size, 2, ctx.image);
- bpf_flush_icache(header, ctx.image + ctx.idx);
-
if (!prog->is_func || extra_pass) {
if (extra_pass && ctx.idx != jit_data->ctx.idx) {
pr_err_once("multi-func JIT bug %d != %d\n",
ctx.idx, jit_data->ctx.idx);
- bpf_jit_binary_free(header);
prog->bpf_func = NULL;
prog->jited = 0;
prog->jited_len = 0;
+ goto out_free_hdr;
+ }
+ if (WARN_ON(bpf_jit_binary_pack_finalize(prog, ro_header,
+ header))) {
+ /* ro_header has been freed */
+ ro_header = NULL;
+ prog = orig_prog;
goto out_off;
}
- bpf_jit_binary_lock_ro(header);
+ /*
+ * The instructions have now been copied to the ROX region from
+ * where they will execute. Now the data cache has to be cleaned to
+ * the PoU and the I-cache has to be invalidated for the VAs.
+ */
+ bpf_flush_icache(ro_header, ctx.ro_image + ctx.idx);
} else {
jit_data->ctx = ctx;
- jit_data->image = image_ptr;
+ jit_data->ro_image = ro_image_ptr;
jit_data->header = header;
+ jit_data->ro_header = ro_header;
}
- prog->bpf_func = (void *)ctx.image;
+
+ prog->bpf_func = (void *)ctx.ro_image;
prog->jited = 1;
prog->jited_len = prog_size;
@@ -1610,6 +1668,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
bpf_jit_prog_release_other(prog, prog == orig_prog ?
tmp : orig_prog);
return prog;
+
+out_free_hdr:
+ if (header) {
+ bpf_arch_text_copy(&ro_header->size, &header->size,
+ sizeof(header->size));
+ bpf_jit_binary_pack_free(ro_header, header);
+ }
+ goto out_off;
}
bool bpf_jit_supports_kfunc_call(void)
@@ -1617,6 +1683,13 @@ bool bpf_jit_supports_kfunc_call(void)
return true;
}
+void *bpf_arch_text_copy(void *dst, void *src, size_t len)
+{
+ if (!aarch64_insn_copy(dst, src, len))
+ return ERR_PTR(-EINVAL);
+ return dst;
+}
+
u64 bpf_jit_alloc_exec_limit(void)
{
return VMALLOC_END - VMALLOC_START;
@@ -2221,3 +2294,27 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type poke_type,
return ret;
}
+
+void bpf_jit_free(struct bpf_prog *prog)
+{
+ if (prog->jited) {
+ struct arm64_jit_data *jit_data = prog->aux->jit_data;
+ struct bpf_binary_header *hdr;
+
+ /*
+ * If we fail the final pass of JIT (from jit_subprogs),
+ * the program may not be finalized yet. Call finalize here
+ * before freeing it.
+ */
+ if (jit_data) {
+ bpf_jit_binary_pack_finalize(prog, jit_data->ro_header,
+ jit_data->header);
+ kfree(jit_data);
+ }
+ hdr = bpf_jit_binary_pack_hdr(prog);
+ bpf_jit_binary_pack_free(hdr, NULL);
+ WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(prog));
+ }
+
+ bpf_prog_unlock_free(prog);
+}
--
2.40.1
The bpf_prog_pack allocator currently uses module_alloc() and
module_memfree() to allocate and free memory. This is not portable
because different architectures use different methods for allocating
memory for BPF programs. Like ARM64 uses vmalloc()/vfree().
Use bpf_jit_alloc_exec() and bpf_jit_free_exec() for memory management
in bpf_prog_pack allocator. Other architectures can override these with
their implementation and will be able to use bpf_prog_pack directly.
Signed-off-by: Puranjay Mohan <[email protected]>
Acked-by: Song Liu <[email protected]>
---
Changes in V3 => v4
- No changes
Changes in V2 => V3:
- No changes
Changes in v1 => v2:
- No code changes.
- Added Acked-by: Song Liu <[email protected]>
kernel/bpf/core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index dc85240a0134..599136cb5096 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -860,7 +860,7 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins
GFP_KERNEL);
if (!pack)
return NULL;
- pack->ptr = module_alloc(BPF_PROG_PACK_SIZE);
+ pack->ptr = bpf_jit_alloc_exec(BPF_PROG_PACK_SIZE);
if (!pack->ptr) {
kfree(pack);
return NULL;
@@ -884,7 +884,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
mutex_lock(&pack_mutex);
if (size > BPF_PROG_PACK_SIZE) {
size = round_up(size, PAGE_SIZE);
- ptr = module_alloc(size);
+ ptr = bpf_jit_alloc_exec(size);
if (ptr) {
bpf_fill_ill_insns(ptr, size);
set_vm_flush_reset_perms(ptr);
@@ -922,7 +922,7 @@ void bpf_prog_pack_free(struct bpf_binary_header *hdr)
mutex_lock(&pack_mutex);
if (hdr->size > BPF_PROG_PACK_SIZE) {
- module_memfree(hdr);
+ bpf_jit_free_exec(hdr);
goto out;
}
@@ -946,7 +946,7 @@ void bpf_prog_pack_free(struct bpf_binary_header *hdr)
if (bitmap_find_next_zero_area(pack->bitmap, BPF_PROG_CHUNK_COUNT, 0,
BPF_PROG_CHUNK_COUNT, 0) == 0) {
list_del(&pack->list);
- module_memfree(pack->ptr);
+ bpf_jit_free_exec(pack->ptr);
kfree(pack);
}
out:
--
2.40.1
On Mon, Jun 26, 2023 at 10:58 AM Puranjay Mohan <[email protected]> wrote:
>
> BPF programs currently consume a page each on ARM64. For systems with many BPF
> programs, this adds significant pressure to instruction TLB. High iTLB pressure
> usually causes slow down for the whole system.
>
> Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> It packs multiple BPF programs into a single huge page. It is currently only
> enabled for the x86_64 BPF JIT.
>
> This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
>
> ====================================================
> Performance Analysis of prog pack allocator on ARM64
> ====================================================
>
> To test the performance of the BPF prog pack allocator on ARM64, a stresser
> tool[2] was built. This tool loads 8 BPF programs on the system and triggers
> 5 of them in an infinite loop by doing system calls.
>
> The runner script starts 20 instances of the above which loads 8*20=160 BPF
> programs on the system, 5*20=100 of which are being constantly triggered.
>
> In the above environment we try to build Python-3.8.4 and try to find different
> iTLB metrics for the compilation done by gcc-12.2.0.
>
> The source code[3] is configured with the following command:
> ./configure --enable-optimizations --with-ensurepip=install
>
> Then the runner script is executed with the following command:
> ./run.sh "perf stat -e ITLB_WALK,L1I_TLB,INST_RETIRED,iTLB-load-misses -a make -j32"
>
> This builds Python while 160 BPF programs are loaded and 100 are being constantly
> triggered and measures iTLB related metrics.
>
> The output of the above command is discussed below before and after enabling the
> BPF prog pack allocator.
>
> The tests were run on qemu-system-aarch64 with 32 cpus, 4G memory, -machine virt,
> -cpu host, and -enable-kvm.
>
> Results
> -------
>
> Before enabling prog pack allocator:
> ------------------------------------
>
> Performance counter stats for 'system wide':
>
> 333278635 ITLB_WALK
> 6762692976558 L1I_TLB
> 25359571423901 INST_RETIRED
> 15824054789 iTLB-load-misses
>
> 189.029769053 seconds time elapsed
>
> After enabling prog pack allocator:
> -----------------------------------
>
> Performance counter stats for 'system wide':
>
> 190333544 ITLB_WALK
> 6712712386528 L1I_TLB
> 25278233304411 INST_RETIRED
> 5716757866 iTLB-load-misses
>
> 185.392650561 seconds time elapsed
>
> Improvements in metrics
> -----------------------
>
> Compilation time ---> 1.92% faster
> iTLB-load-misses/Sec (Less is better) ---> 63.16% decrease
> ITLB_WALK/1000 INST_RETIRED (Less is better) ---> 42.71% decrease
> ITLB_Walk/L1I_TLB (Less is better) ---> 42.47% decrease
>
> [1] https://lore.kernel.org/bpf/[email protected]/
> [2] https://github.com/puranjaymohan/BPF-Allocator-Bench
> [3] https://www.python.org/ftp/python/3.8.4/Python-3.8.4.tgz
>
> Chanes in V3 => V4: Changes only in 3rd patch
> 1. Fix the I-cache maintenance: Clean the data cache and invalidate the i-Cache
> only *after* the instructions have been copied to the ROX region.
>
> Chanes in V2 => V3: Changes only in 3rd patch
> 1. Set prog = orig_prog; in the failure path of bpf_jit_binary_pack_finalize()
> call.
> 2. Add comments explaining the usage of the offsets in the exception table.
>
> Changes in v1 => v2:
> 1. Make the naming consistent in the 3rd patch:
> ro_image and image
> ro_header and header
> ro_image_ptr and image_ptr
> 2. Use names dst/src in place of addr/opcode in second patch.
> 3. Add Acked-by: Song Liu <[email protected]> in 1st and 2nd patch.
>
> Puranjay Mohan (3):
> bpf: make bpf_prog_pack allocator portable
> arm64: patching: Add aarch64_insn_copy()
> bpf, arm64: use bpf_jit_binary_pack_alloc
>
> arch/arm64/include/asm/patching.h | 1 +
> arch/arm64/kernel/patching.c | 39 ++++++++
> arch/arm64/net/bpf_jit_comp.c | 145 +++++++++++++++++++++++++-----
> kernel/bpf/core.c | 8 +-
> 4 files changed, 165 insertions(+), 28 deletions(-)
>
> --
> 2.40.1
>
>
FWIW
Acked-by: Florent Revest <[email protected]>
Thanks for this Puranjay!
Hi Mark,
On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> BPF programs currently consume a page each on ARM64. For systems with many BPF
> programs, this adds significant pressure to instruction TLB. High iTLB pressure
> usually causes slow down for the whole system.
>
> Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> It packs multiple BPF programs into a single huge page. It is currently only
> enabled for the x86_64 BPF JIT.
>
> This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
>
> ====================================================
> Performance Analysis of prog pack allocator on ARM64
> ====================================================
>
> To test the performance of the BPF prog pack allocator on ARM64, a stresser
> tool[2] was built. This tool loads 8 BPF programs on the system and triggers
> 5 of them in an infinite loop by doing system calls.
>
> The runner script starts 20 instances of the above which loads 8*20=160 BPF
> programs on the system, 5*20=100 of which are being constantly triggered.
>
> In the above environment we try to build Python-3.8.4 and try to find different
> iTLB metrics for the compilation done by gcc-12.2.0.
>
> The source code[3] is configured with the following command:
> ./configure --enable-optimizations --with-ensurepip=install
>
> Then the runner script is executed with the following command:
> ./run.sh "perf stat -e ITLB_WALK,L1I_TLB,INST_RETIRED,iTLB-load-misses -a make -j32"
>
> This builds Python while 160 BPF programs are loaded and 100 are being constantly
> triggered and measures iTLB related metrics.
>
> The output of the above command is discussed below before and after enabling the
> BPF prog pack allocator.
>
> The tests were run on qemu-system-aarch64 with 32 cpus, 4G memory, -machine virt,
> -cpu host, and -enable-kvm.
>
> Results
> -------
>
> Before enabling prog pack allocator:
> ------------------------------------
>
> Performance counter stats for 'system wide':
>
> 333278635 ITLB_WALK
> 6762692976558 L1I_TLB
> 25359571423901 INST_RETIRED
> 15824054789 iTLB-load-misses
>
> 189.029769053 seconds time elapsed
>
> After enabling prog pack allocator:
> -----------------------------------
>
> Performance counter stats for 'system wide':
>
> 190333544 ITLB_WALK
> 6712712386528 L1I_TLB
> 25278233304411 INST_RETIRED
> 5716757866 iTLB-load-misses
>
> 185.392650561 seconds time elapsed
>
> Improvements in metrics
> -----------------------
>
> Compilation time ---> 1.92% faster
> iTLB-load-misses/Sec (Less is better) ---> 63.16% decrease
> ITLB_WALK/1000 INST_RETIRED (Less is better) ---> 42.71% decrease
> ITLB_Walk/L1I_TLB (Less is better) ---> 42.47% decrease
>
> [1] https://lore.kernel.org/bpf/[email protected]/
> [2] https://github.com/puranjaymohan/BPF-Allocator-Bench
> [3] https://www.python.org/ftp/python/3.8.4/Python-3.8.4.tgz
>
> Chanes in V3 => V4: Changes only in 3rd patch
> 1. Fix the I-cache maintenance: Clean the data cache and invalidate the i-Cache
> only *after* the instructions have been copied to the ROX region.
If you get a chance to take another look at the v4 changes from Puranjay and
in case they look good to you reply with an Ack, that would be great.
Thanks,
Daniel
On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> Hi Mark,
Hi Daniel,
> On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > usually causes slow down for the whole system.
> >
> > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > It packs multiple BPF programs into a single huge page. It is currently only
> > enabled for the x86_64 BPF JIT.
> >
> > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> If you get a chance to take another look at the v4 changes from Puranjay and
> in case they look good to you reply with an Ack, that would be great.
Sure -- this is on my queue of things to look at; it might just take me a few
days to get the time to give this a proper look.
Thanks,
Mark.
On 7/3/23 7:15 PM, Mark Rutland wrote:
[...]
>> On 6/26/23 10:58 AM, Puranjay Mohan wrote:
>>> BPF programs currently consume a page each on ARM64. For systems with many BPF
>>> programs, this adds significant pressure to instruction TLB. High iTLB pressure
>>> usually causes slow down for the whole system.
>>>
>>> Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
>>> It packs multiple BPF programs into a single huge page. It is currently only
>>> enabled for the x86_64 BPF JIT.
>>>
>>> This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
>
>> If you get a chance to take another look at the v4 changes from Puranjay and
>> in case they look good to you reply with an Ack, that would be great.
>
> Sure -- this is on my queue of things to look at; it might just take me a few
> days to get the time to give this a proper look.
Awesome, thanks Mark!
Hi Mark,
On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
>
> On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > Hi Mark,
>
> Hi Daniel,
>
> > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > usually causes slow down for the whole system.
> > >
> > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > It packs multiple BPF programs into a single huge page. It is currently only
> > > enabled for the x86_64 BPF JIT.
> > >
> > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
>
> > If you get a chance to take another look at the v4 changes from Puranjay and
> > in case they look good to you reply with an Ack, that would be great.
>
> Sure -- this is on my queue of things to look at; it might just take me a few
> days to get the time to give this a proper look.
>
> Thanks,
> Mark.
I am eagerly looking forward to your feedback on this series.
Thanks,
Puranjay
Hi Mark,
I am really looking forward to your feedback on this series.
On Mon, Jul 17, 2023 at 9:50 AM Puranjay Mohan <[email protected]> wrote:
>
> Hi Mark,
>
> On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
> >
> > On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > > Hi Mark,
> >
> > Hi Daniel,
> >
> > > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > > usually causes slow down for the whole system.
> > > >
> > > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > > It packs multiple BPF programs into a single huge page. It is currently only
> > > > enabled for the x86_64 BPF JIT.
> > > >
> > > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> >
> > > If you get a chance to take another look at the v4 changes from Puranjay and
> > > in case they look good to you reply with an Ack, that would be great.
> >
> > Sure -- this is on my queue of things to look at; it might just take me a few
> > days to get the time to give this a proper look.
> >
> > Thanks,
> > Mark.
>
> I am eagerly looking forward to your feedback on this series.
>
> Thanks,
> Puranjay
Thanks,
Puranjay
On Sun, Jul 30, 2023 at 10:22 AM Puranjay Mohan <[email protected]> wrote:
>
> Hi Mark,
> I am really looking forward to your feedback on this series.
>
> On Mon, Jul 17, 2023 at 9:50 AM Puranjay Mohan <[email protected]> wrote:
> >
> > Hi Mark,
> >
> > On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
> > >
> > > On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > > > Hi Mark,
> > >
> > > Hi Daniel,
> > >
> > > > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > > > usually causes slow down for the whole system.
> > > > >
> > > > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > > > It packs multiple BPF programs into a single huge page. It is currently only
> > > > > enabled for the x86_64 BPF JIT.
> > > > >
> > > > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> > >
> > > > If you get a chance to take another look at the v4 changes from Puranjay and
> > > > in case they look good to you reply with an Ack, that would be great.
> > >
> > > Sure -- this is on my queue of things to look at; it might just take me a few
> > > days to get the time to give this a proper look.
> > >
> > > Thanks,
> > > Mark.
> >
> > I am eagerly looking forward to your feedback on this series.
Mark, Catalin, Florent, KP,
This patch set was submitted on June 26 !
It's not acceptable to delay review for so long.
Please review asap.
Hi Alexei,
On Wed, Aug 02, 2023 at 02:02:39PM -0700, Alexei Starovoitov wrote:
> On Sun, Jul 30, 2023 at 10:22 AM Puranjay Mohan <[email protected]> wrote:
> >
> > Hi Mark,
> > I am really looking forward to your feedback on this series.
> >
> > On Mon, Jul 17, 2023 at 9:50 AM Puranjay Mohan <[email protected]> wrote:
> > >
> > > Hi Mark,
> > >
> > > On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
> > > >
> > > > On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > > > > Hi Mark,
> > > >
> > > > Hi Daniel,
> > > >
> > > > > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > > > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > > > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > > > > usually causes slow down for the whole system.
> > > > > >
> > > > > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > > > > It packs multiple BPF programs into a single huge page. It is currently only
> > > > > > enabled for the x86_64 BPF JIT.
> > > > > >
> > > > > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> > > >
> > > > > If you get a chance to take another look at the v4 changes from Puranjay and
> > > > > in case they look good to you reply with an Ack, that would be great.
> > > >
> > > > Sure -- this is on my queue of things to look at; it might just take me a few
> > > > days to get the time to give this a proper look.
> > > >
> > > > Thanks,
> > > > Mark.
> > >
> > > I am eagerly looking forward to your feedback on this series.
>
> Mark, Catalin, Florent, KP,
>
> This patch set was submitted on June 26 !
I appreciate this was sent a while ago, but I have been stuck on some urgent
bug-fixing for the last few weeks, and my review bandwidth is therfore very
limited.
Given Puranjay had previously told me he was doing this as a side project for
fun, and given no-one had told me this was urgent, I assumed that this wasn't a
major blocker and could wait.
I should have sent a holding reply to that effect; sorry.
The series addresses my original concern. However, in looking at it I think
there may me a wider potential isssue w.r.t. the way instruction memory gets
reused, because as writtten today the architecture doesn't seem to have a
guarantee on when instruction fetches are completed and therefore when it's
safe to modify instruction memory. Usually we're saved by TLB maintenance,
which this series avoids by design.
I unfortunately haven't had the time to dig into that, poke our architects,
etc.
So how urgent is this?
Thanks,
Mark.
On Thu, Aug 3, 2023 at 4:13 AM Mark Rutland <[email protected]> wrote:
>
> Hi Alexei,
>
> On Wed, Aug 02, 2023 at 02:02:39PM -0700, Alexei Starovoitov wrote:
> > On Sun, Jul 30, 2023 at 10:22 AM Puranjay Mohan <[email protected]> wrote:
> > >
> > > Hi Mark,
> > > I am really looking forward to your feedback on this series.
> > >
> > > On Mon, Jul 17, 2023 at 9:50 AM Puranjay Mohan <[email protected]> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
> > > > >
> > > > > On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > > > > > Hi Mark,
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > > > > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > > > > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > > > > > usually causes slow down for the whole system.
> > > > > > >
> > > > > > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > > > > > It packs multiple BPF programs into a single huge page. It is currently only
> > > > > > > enabled for the x86_64 BPF JIT.
> > > > > > >
> > > > > > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> > > > >
> > > > > > If you get a chance to take another look at the v4 changes from Puranjay and
> > > > > > in case they look good to you reply with an Ack, that would be great.
> > > > >
> > > > > Sure -- this is on my queue of things to look at; it might just take me a few
> > > > > days to get the time to give this a proper look.
> > > > >
> > > > > Thanks,
> > > > > Mark.
> > > >
> > > > I am eagerly looking forward to your feedback on this series.
> >
> > Mark, Catalin, Florent, KP,
> >
> > This patch set was submitted on June 26 !
>
> I appreciate this was sent a while ago, but I have been stuck on some urgent
> bug-fixing for the last few weeks, and my review bandwidth is therfore very
> limited.
>
> Given Puranjay had previously told me he was doing this as a side project for
> fun, and given no-one had told me this was urgent, I assumed that this wasn't a
> major blocker and could wait.
>
> I should have sent a holding reply to that effect; sorry.
>
> The series addresses my original concern. However, in looking at it I think
> there may me a wider potential isssue w.r.t. the way instruction memory gets
> reused, because as writtten today the architecture doesn't seem to have a
> guarantee on when instruction fetches are completed and therefore when it's
> safe to modify instruction memory. Usually we're saved by TLB maintenance,
> which this series avoids by design.
>
> I unfortunately haven't had the time to dig into that, poke our architects,
> etc.
>
> So how urgent is this?
The performance wins are substantial.
We'd like to realize them sooner than later.
On Thu, Aug 3, 2023 at 6:16 PM Alexei Starovoitov
<[email protected]> wrote:
>
> On Thu, Aug 3, 2023 at 4:13 AM Mark Rutland <[email protected]> wrote:
> >
> > Hi Alexei,
> >
> > On Wed, Aug 02, 2023 at 02:02:39PM -0700, Alexei Starovoitov wrote:
> > > Mark, Catalin, Florent, KP,
Maybe you've missed my Acked-by for the series Alexei ?
https://lore.kernel.org/all/CABRcYmLAzhG=o2wcBNBtFP34Aj3+eYsEMtMREDT7SqNzBc9-qw@mail.gmail.com/
> > > This patch set was submitted on June 26 !
> >
> > I appreciate this was sent a while ago, but I have been stuck on some urgent
> > bug-fixing for the last few weeks, and my review bandwidth is therfore very
> > limited.
> >
> > Given Puranjay had previously told me he was doing this as a side project for
> > fun, and given no-one had told me this was urgent, I assumed that this wasn't a
> > major blocker and could wait.
> >
> > I should have sent a holding reply to that effect; sorry.
> >
> > The series addresses my original concern. However, in looking at it I think
> > there may me a wider potential isssue w.r.t. the way instruction memory gets
> > reused, because as writtten today the architecture doesn't seem to have a
> > guarantee on when instruction fetches are completed and therefore when it's
> > safe to modify instruction memory. Usually we're saved by TLB maintenance,
> > which this series avoids by design.
But I must say that this sits firmly outside of my knowledge of the
arm architectural details and I would totally miss this sort of nuance
so this is best handled by arm64 maintainers :)
> > I unfortunately haven't had the time to dig into that, poke our architects,
> > etc.
> >
> > So how urgent is this?
>
> The performance wins are substantial.
> We'd like to realize them sooner than later.
I've worked with Mark before, I know for a fact that he is dragged in
all directions. Until we figure out a way to clone him we should try
to not burn him out too often... :)
Hi Mark,
On Thu, Aug 3, 2023 at 1:13 PM Mark Rutland <[email protected]> wrote:
>
> Hi Alexei,
>
> On Wed, Aug 02, 2023 at 02:02:39PM -0700, Alexei Starovoitov wrote:
> > On Sun, Jul 30, 2023 at 10:22 AM Puranjay Mohan <[email protected]> wrote:
> > >
> > > Hi Mark,
> > > I am really looking forward to your feedback on this series.
> > >
> > > On Mon, Jul 17, 2023 at 9:50 AM Puranjay Mohan <[email protected]> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > On Mon, Jul 3, 2023 at 7:15 PM Mark Rutland <[email protected]> wrote:
> > > > >
> > > > > On Mon, Jul 03, 2023 at 06:40:21PM +0200, Daniel Borkmann wrote:
> > > > > > Hi Mark,
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > > On 6/26/23 10:58 AM, Puranjay Mohan wrote:
> > > > > > > BPF programs currently consume a page each on ARM64. For systems with many BPF
> > > > > > > programs, this adds significant pressure to instruction TLB. High iTLB pressure
> > > > > > > usually causes slow down for the whole system.
> > > > > > >
> > > > > > > Song Liu introduced the BPF prog pack allocator[1] to mitigate the above issue.
> > > > > > > It packs multiple BPF programs into a single huge page. It is currently only
> > > > > > > enabled for the x86_64 BPF JIT.
> > > > > > >
> > > > > > > This patch series enables the BPF prog pack allocator for the ARM64 BPF JIT.
> > > > >
> > > > > > If you get a chance to take another look at the v4 changes from Puranjay and
> > > > > > in case they look good to you reply with an Ack, that would be great.
> > > > >
> > > > > Sure -- this is on my queue of things to look at; it might just take me a few
> > > > > days to get the time to give this a proper look.
> > > > >
> > > > > Thanks,
> > > > > Mark.
> > > >
> > > > I am eagerly looking forward to your feedback on this series.
> >
> > Mark, Catalin, Florent, KP,
> >
> > This patch set was submitted on June 26 !
>
> I appreciate this was sent a while ago, but I have been stuck on some urgent
> bug-fixing for the last few weeks, and my review bandwidth is therfore very
> limited.
>
> Given Puranjay had previously told me he was doing this as a side project for
> fun, and given no-one had told me this was urgent, I assumed that this wasn't a
> major blocker and could wait.
Yes, I am just doing it as a side project for fun. It is not a major blocker.
>
> I should have sent a holding reply to that effect; sorry.
>
> The series addresses my original concern. However, in looking at it I think
> there may me a wider potential isssue w.r.t. the way instruction memory gets
> reused, because as writtten today the architecture doesn't seem to have a
> guarantee on when instruction fetches are completed and therefore when it's
> safe to modify instruction memory. Usually we're saved by TLB maintenance,
> which this series avoids by design.
>
> I unfortunately haven't had the time to dig into that, poke our architects,
> etc.
>
> So how urgent is this?
This is not urgent as this is not a blocker for anything.
I just wanted to know if there was something pending from my side.
Please review it whenever you have spare time. Thanks for helping me debug the
issue with the cache maintenance.
Thanks,
Puranjay
On Thu, Aug 03, 2023 at 12:13:00PM +0100, Mark Rutland wrote:
[...]
> However, in looking at it I think
> there may me a wider potential isssue w.r.t. the way instruction memory gets
> reused, because as writtten today the architecture doesn't seem to have a
> guarantee on when instruction fetches are completed and therefore when it's
> safe to modify instruction memory. Usually we're saved by TLB maintenance,
> which this series avoids by design.
Just to confirm on this point specifically, per discussions with our
architects, the (architectural) execution of an instruction ensures that there
are no outstanding fetches for prior instructions. IIUC that will be clarified
the next release of the ARM ARM.
So as long as we're certain all threads have left the old code (e.g. via a
flag, RCU tasks rude synchronization, whatever) before we overwrite slots in
the shared buffer, we should be good.
We will need to be very careful with the maintenance when installing new code
into the shared buffer (e.g. we will require an IPI to all other CPUs), but
that should be relatively simple.
I'll go review the latest patches with that in mind.
Thanks,
Mark.