On Fri, Feb 9, 2024 at 11:41 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > A few questions on the patch. > > 1. Is the expectation that user space would use syscall progs to > manipulate mappings in the arena? any sleepable prog can alloc/free. all other progs can access arena. > 2. I may have missed it, but which memcg are the allocations being > accounted against? Will it be the process that created the map? > When trying to explore bpf_map_alloc_pages, I could not figure out if > the obj_cgroup was being looked up anywhere. > I think it would be nice if it were accounted for against the caller > of bpf_map_alloc_pages, since potentially the arena map can be shared > across multiple processes. > Tying it to bpf_map on bpf_map_alloc may be too coarse for arena maps. yeah. will switch to memcg accounting the way it's done for all other maps. It will be similar to bpf_map_kmalloc_node. I don't think we should deviate from the standard. bpf_map_save_memcg() is already done for bpf_arena. I simply forgot to wrap alloc pages with set_active_memcg. > 3. A bit tangential, but what would be the path to having huge page > mappings look like (mostly from an interface standpoint)? I gather we > could use the flags argument on the kernel side, and if 1 is true > above, it would mean userspace would do it from inside a syscall > program and then trigger a page fault? Because experience with use > case 1 in the commit log suggests it is desirable to have such memory > be backed by huge pages to reduce TLB misses. Right. It will be a new flag.
