On Fri, Aug 28, 2015 at 06:02:37PM -0400, Tejun Heo wrote: > On the default hierarchy, all memory consumption will be accounted > together and controlled by the same set of limits. Enable kmemcg on > the default hierarchy by default. Boot parameter "disable_kmemcg" can > be specified to turn it off. > > v2: - v1 triggered oops on nested cgroup creations. Moved enabling > mechanism to memcg_propagate_kmem(). > - Bypass busy test on kmem activation as it's unnecessary and gets > confused by controller being enabled on a cgroup which already > has processes. > - "disable_kmemcg" boot param added. > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> The old distinction between kernel and user memory really doesn't make sense and should not be maintained. The dentry and inode caches are a significant share of overall memory consumed in common workloads, and that is memory unambiguously coupled to userspace activity. I'd go as far as removing CONFIG_MEMCG_KMEM altogether because it strikes me as a completely unreasonable choice to give to the user (outside of maybe CONFIG_EXPERT). What CONFIG_MEMCG should really capture is all memory that can grow significantly in size and can be associated directly with userspace behavior. If there are types of memory that turn out to be very costly to account and track, we can still go back and conceive an interface that lets the user select the types of memory he doesn't need tracked. But the KMEMCG differentation is an arbitrary, and mostly historical distinction that we shouldn't continue to present to users. -- 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>