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

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

 




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 ?

Christophe




[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