On Wed 11-10-17 12:03:59, Shakeel Butt wrote:
> The allocations from filp cache can be directly triggered by user
> space applications. A buggy application can consume a significant
> amount of unaccounted system memory. Though we have not noticed
> such buggy applications in our production but upon close inspection,
> we found that a lot of machines spend very significant amount of
> memory on these caches.
>
> One way to limit allocations from filp cache is to set system level
> 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 can charge filp to kmemcg and set the
> maximum limit very high and let the memory limit of each user limit
> the number of files they can open and indirectly limiting their
> allocations from filp cache.
>
> One side effect of this change is that it will allow _sysctl() to
> return ENOMEM and the man page of _sysctl() does not specify that.
> However the man page also discourages to use _sysctl() at all.
>
> Signed-off-by: Shakeel Butt <[email protected]>
OK, this makes more sense than the original patch. struct file is not
really large (248B on my system) so I am not sure how much this helps
though. Anyway, I have no objections to the patch but I do not feel
qualified to ack it either.
> ---
>
> Changelog since v1:
> - removed names_cache charging to kmemcg
>
> fs/file_table.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/file_table.c b/fs/file_table.c
> index 61517f57f8ef..567888cdf7d3 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -312,7 +312,7 @@ void put_filp(struct file *file)
> void __init files_init(void)
> {
> 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);
> }
>
> --
> 2.15.0.rc0.271.g36b669edcc-goog
--
Michal Hocko
SUSE Labs
