On 5/10/25 05:11, Shakeel Butt wrote: > Before answering the questions, let me clarify that this series is > continuation of the work which added similar support for page allocator > and related memcg charging and now the work is happening for > kmalloc/slab allocations. Alexei has a proposal on reentrant kmalloc and > here I am providing how memcg charging for that (reentrant kmalloc) > should work. > > Next let me take a stab in answering the questions and BPF folks can > correct me if I am wrong. From what I understand, users can attach BPF > programs at almost any place in kernel and those BPF programs can do > memory allocations. This line of work is to make those allocations work > if the any such BPF attach point is triggered in mni context. > > Before this line of work (reentrant page and slab allocators), I think > BPF had its internal cache but it was very limited and can easily fail > allocation requests (please BPF folks correct me if I am wrong). This > was discussed in LSFMM this year as well. > > Now regarding the impact to the users. First there will not be any > negative impact on the non-users of this feature. For the value this > feature will provide to users, I think this line of work will make BPF > programs of the users more reliable with better allocation behavior. > BPF folks, please add more comments for the value of these features. Yes and I think this part of cover letter is also important: > There will be a followup series which will make kernel memory charging > reentrant for irq and will be able to do without disabling irqs. The "without disabling irqs" part will improve performance for all users.
