From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v5 14/14] Add documentation about the kmem controller Date: Tue, 16 Oct 2012 23:02:46 +0400 Message-ID: <507DAF56.9010403@parallels.com> References: <1350382611-20579-1-git-send-email-glommer@parallels.com> <1350382611-20579-15-git-send-email-glommer@parallels.com> <0000013a6ad26c73-d043cf97-c44a-45c1-9cae-0a962e93a005-000000@email.amazonses.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0000013a6ad26c73-d043cf97-c44a-45c1-9cae-0a962e93a005-000000-p/GC64/jrecnJqMo6gzdpkEOCMrvLtNR@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Christoph Lameter Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mel Gorman , Tejun Heo , Andrew Morton , Michal Hocko , Johannes Weiner , kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, David Rientjes , Pekka Enberg , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Frederic Weisbecker , Pekka Enberg , Suleiman Souhlal On 10/16/2012 10:25 PM, Christoph Lameter wrote: > On Tue, 16 Oct 2012, Glauber Costa wrote: > >> >> + memory.kmem.limit_in_bytes # set/show hard limit for kernel memory >> + memory.kmem.usage_in_bytes # show current kernel memory allocation >> + memory.kmem.failcnt # show the number of kernel memory usage hits limits >> + memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded > > Does it actually make sense to limit kernel memory? Yes. > The user generally has > no idea how much kernel memory a process is using and kernel changes can > change the memory footprint. Given the fuzzy accounting in the kernel a > large cache refill (if someone configures the slab batch count to be > really big f.e.) can account a lot of memory to the wrong cgroup. The > allocation could fail. > It heavily depends on the type of the user. The user may not know how much kernel memory precisely will be used, but he/she usually knows quite well that it shouldn't be all cgroups together shouldn't use more than available in the system. IOW: It is usually safe to overcommit user memory, but not kernel memory. This is absolutely crucial in any high-density container host, and we've been doing this in OpenVZ for ages (in an uglier form than this) > Limiting the total memory use of a process (U+K) would make more sense I > guess. Only U is probably sufficient? In what way would a limitation on > kernel memory in use be good? > The kmem counter is also fed into the u counter. If the limit value of "u" is equal or greater than "k", this is actually what you are doing. For a lot of application yes, only U is sufficient. This is the default, btw, since "k" is only even accounted if you set the limit. All those use cases are detailed a bit below in this file. A limitation of kernel memory use would be good, for example, to prevent abuse from non-trusted containers in a high density, shared, container environment.