On Mon, Apr 18, 2022 at 05:44:19PM -0700, Luis Chamberlain wrote: > On Mon, Apr 18, 2022 at 01:06:36PM +0300, Mike Rapoport wrote: > > Hi, > > > > On Sat, Apr 16, 2022 at 10:26:08PM +0000, Song Liu wrote: > > > > On Apr 16, 2022, at 1:30 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > Maybe I am missing something, but I really don't think this is ready > > > > for prime-time. We should effectively disable it all, and have people > > > > think through it a lot more. > > > > > > This has been discussed on lwn.net: https://lwn.net/Articles/883454/. > > > AFAICT, the biggest concern is whether reserving minimal 2MB for BPF > > > programs is a good trade-off for memory usage. This is again my fault > > > not to state the motivation clearly: the primary gain comes from less > > > page table fragmentation and thus better iTLB efficiency. > > > > Reserving 2MB pages for BPF programs will indeed reduce the fragmentation, > > but OTOH it will reduce memory utilization. If for large systems this may > > not be an issue, on smaller machines trading off memory for iTLB > > performance may be not that obvious. > > So the current optimization at best should be a kconfig option? Maybe not and it'll be fine on smaller systems, but from what I see the bpf_prog_pack implementation didn't consider them. And if we move the caches from BPF to vmalloc or page allocator that would be much less of an issue. > > I believe that "allocate huge page and split it to basic pages to hand out > > to users" concept should be implemented at page allocator level and I > > posted and RFC for this a while ago: > > > > https://lore.kernel.org/all/20220127085608.306306-1-rppt@xxxxxxxxxx/ > > Neat, so although eBPF is a big user, are there some use cases outside > that immediately benefit? Anything that uses set_memory APIs could benefit from this. Except eBPF and other module_alloc() users, there is secretmem that also fractures the direct map and actually that was my initial use case for these patches. Another possible use-case can be protection of page tables with PKS: https://lore.kernel.org/lkml/20210505003032.489164-1-rick.p.edgecombe@xxxxxxxxx/ Vlastimil also mentioned that SEV-SNP could use such caching mechanism, but I don't know the details. > LUis -- Sincerely yours, Mike.
