lkml.org 
[lkml]   [2017]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs, mm: account filp and names caches to kmemcg
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

\
 
 \ /
  Last update: 2017-10-09 08:25    [W:2.959 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site