On Mon, Feb 26, 2024 at 12:01 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Fri, 5 Jan 2024 at 16:21, Alexander Mikhalitsyn > <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote: > > > > fuse_dev_alloc() is called from the process context and it makes > > sense to properly account allocated memory to the kmemcg as these > > allocations are for long living objects. Hi Miklos, Sorry, this thread just got lost in my inbox. I was revisiting and rebasing fuse idmapped mounts support series and found this again. > > Are the rules about when to use __GFP_ACCOUNT and when not documented somewhere? The only doc I found is this (memory-allocation.rst): >Untrusted allocations triggered from userspace should be a subject >of kmem accounting and must have ``__GFP_ACCOUNT`` bit set. > > I notice that most filesystem objects are allocated with > __GFP_ACCOUNT, but struct super_block isn't. Is there a reason for > that? I guess that it just wasn't yet covered with memcg accounting. I can send a patch to account struct super_block too. These days, it's pretty safe to use __GFP_ACCOUNT almost anywhere, because even if memcg is not determined in a current caller context then memcg charge will be skipped (look into __memcg_slab_post_alloc_hook() function). Let's ask what our friends who take care of mmcontrol.c think about this. +CC Johannes Weiner <hannes@xxxxxxxxxxx> +CC Michal Hocko <mhocko@xxxxxxxxxx> +CC Roman Gushchin <roman.gushchin@xxxxxxxxx> +CC Shakeel Butt <shakeel.butt@xxxxxxxxx> I have also added Christian because he might be interested in accounting for struct super_block. Kind regards, Alex > > Thanks, > Miklos
