Re: [RFC PATCH 0/3] enable bpf_prog_pack allocator for powerpc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 18/11/22 2:21 pm, Christophe Leroy wrote:


Le 18/11/2022 à 09:39, Hari Bathini a écrit :


On 17/11/22 12:29 pm, Christophe Leroy wrote:


Le 16/11/2022 à 18:01, Hari Bathini a écrit :


On 16/11/22 12:14 am, Christophe Leroy wrote:


Le 14/11/2022 à 18:27, Christophe Leroy a écrit :


Le 14/11/2022 à 15:47, Hari Bathini a écrit :
Hi Christophe,

On 11/11/22 4:55 pm, Christophe Leroy wrote:
Le 10/11/2022 à 19:43, Hari Bathini a écrit :
Most BPF programs are small, but they consume a page each. For
systems
with busy traffic and many BPF programs, this may also add
significant
pressure on instruction TLB. High iTLB pressure usually slows down
the
whole system causing visible performance degradation for production
workloads.

bpf_prog_pack, a customized allocator that packs multiple bpf
programs
into preallocated memory chunks, was proposed [1] to address it.
This
series extends this support on powerpc.

Patches 1 & 2 add the arch specific functions needed to support
this
feature. Patch 3 enables the support for powerpc. The last patch
ensures cleanup is handled racefully.


Tested the changes successfully on a PowerVM. patch_instruction(),
needed for bpf_arch_text_copy(), is failing for ppc32. Debugging
it.
Posting the patches in the meanwhile for feedback on these changes.

I did a quick test on ppc32, I don't get such a problem, only
something
wrong in the dump print as traps intructions only are dumped, but
tcpdump works as expected:

Thanks for the quick test. Could you please share the config you
used.
I am probably missing a few knobs in my conifg...



I also managed to test it on QEMU. The config is based on
pmac32_defconfig.

I had the same config but hit this problem:

       # echo 1 > /proc/sys/net/core/bpf_jit_enable; modprobe test_bpf
       test_bpf: #0 TAX
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 96 at arch/powerpc/net/bpf_jit_comp.c:367
bpf_int_jit_compile+0x8a0/0x9f8

I get no such problem, on QEMU, and I checked the .config has:

CONFIG_STRICT_KERNEL_RWX=y
CONFIG_STRICT_MODULE_RWX=y

Yeah. That did the trick.

Interesting. I guess we have to find out why it fails when those config
are missing.

Maybe module code plays with RO and NX flags even if
CONFIG_STRICT_MODULE_RWX is not selected ?

Need to look at the code closely but fwiw, observing same failure on
64-bit as well with !STRICT_RWX...

Thanks
Hari



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux