summaryrefslogtreecommitdiffstats
path: root/mm/slub.c
diff options
context:
space:
mode:
authorShakeel Butt <shakeelb@google.com>2017-11-15 17:35:44 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-11-15 18:21:04 -0800
commitf3f7c09355784b02e49853dd1403d0e2d4f991c6 (patch)
treee380571fb09bbfb0d05803fd380a8eb1d7482d3d /mm/slub.c
parentaf5b0f6a09e42c9f4fa87735f2a366748767b686 (diff)
downloadlinux-f3f7c09355784b02e49853dd1403d0e2d4f991c6.tar.bz2
fs, mm: account filp cache to kmemcg
The allocations from filp cache can be directly triggered by userspace 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. Link: http://lkml.kernel.org/r/20171011190359.34926-1-shakeelb@google.com Signed-off-by: Shakeel Butt <shakeelb@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Greg Thelen <gthelen@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/slub.c')
0 files changed, 0 insertions, 0 deletions