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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
