Re: [PATCH] fs, mm: account filp and names caches to kmemcg

[Michal Hocko]

On Fri 06-10-17 12:33:03, Shakeel Butt wrote:
> >>       names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0,
> >> -                     SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> >> +                     SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
> >
> > I might be wrong but isn't name cache only holding temporary objects
> > used for path resolution which are not stored anywhere?
> >
> 
> Even though they're temporary, many containers can together use a
> significant amount of transient uncharged memory. We've seen machines
> with 100s of MiBs in names_cache.

Yes that might be possible but are we prepared for random ENOMEM from
vfs calls which need to allocate a temporary name?

> 
> >>       filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
> >> -                     SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
> >> +                     SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL);
> >>       percpu_counter_init(&nr_files, 0, GFP_KERNEL);
> >>  }
> >
> > Don't we have a limit for the maximum number of open files?
> >
> 
> Yes, there is a system limit of maximum number of open files. However
> this limit is shared between different users on the system and one
> user can hog this resource. To cater that, we set the maximum limit
> very high and let the memory limit of each user limit the number of
> files they can open.

Similarly here. Are all syscalls allocating a fd prepared to return
ENOMEM?

-- 
Michal Hocko
SUSE Labs