On Sun, Jun 4, 2023 at 2:40 PM Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > On Sun, Jun 04, 2023 at 02:22:30PM -0700, Song Liu wrote: > > On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet > > <kent.overstreet@xxxxxxxxx> wrote: > > > > > > On Fri, Jun 02, 2023 at 11:20:58AM -0700, Song Liu wrote: > > > > IIUC, arm64 uses VMALLOC address space for BPF programs. The reason > > > > is each BPF program uses at least 64kB (one page) out of the 128MB > > > > address space. Puranjay Mohan (CC'ed) is working on enabling > > > > bpf_prog_pack for arm64. Once this work is done, multiple BPF programs > > > > will be able to share a page. Will this improvement remove the need to > > > > specify a different address range for BPF programs? > > > > > > Can we please stop working on BPF specific sub page allocation and focus > > > on doing this in mm/? This never should have been in BPF in the first > > > place. > > > > That work is mostly independent of the allocator work we are discussing here. > > The goal Puranjay's work is to enable the arm64 BPF JIT engine to use a > > ROX allocator. The allocator could be the bpf_prog_pack allocator, or jitalloc, > > or module_alloc_type. Puranjay is using bpf_prog_alloc for now. But once > > jitalloc or module_alloc_type (either one) is merged, we will migrate BPF > > JIT engines (x86_64 and arm64) to the new allocator and then tear down > > bpf_prog_pack. > > > > Does this make sense? > > Yeah, as long as that's the plan. Maybe one of you could tell us what > issues were preventing prog_pack from being used in the first place, it > might be relevant - this is the time to get the new allocator API right. The JIT engine does a lot of writes. Instead of doing many text_poke(), we are using a temporary RW write buffer, and then do text_poke_copy() at the end. To make this work, we need the JIT engine to be able to handle an RW temporary buffer and an RO final memory region. There is nothing preventing prog_pack to work. It is just we need to do the work. Thanks, Song
