From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754022AbaGUJH3 (ORCPT ); Mon, 21 Jul 2014 05:07:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45459 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753757AbaGUJH2 (ORCPT ); Mon, 21 Jul 2014 05:07:28 -0400 Date: Mon, 21 Jul 2014 11:07:24 +0200 From: Michal Hocko To: Vladimir Davydov Cc: Johannes Weiner , linux-mm@kvack.org, LKML , Tejun Heo , Hugh Dickins , Greg Thelen , Glauber Costa , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro Subject: Re: [RFC PATCH] memcg: export knobs for the defaul cgroup hierarchy Message-ID: <20140721090724.GA8393@dhcp22.suse.cz> References: <1405521578-19988-1-git-send-email-mhocko@suse.cz> <20140716155814.GZ29639@cmpxchg.org> <20140718154443.GM27940@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140718154443.GM27940@esperanza> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 18-07-14 19:44:43, Vladimir Davydov wrote: > On Wed, Jul 16, 2014 at 11:58:14AM -0400, Johannes Weiner wrote: > > On Wed, Jul 16, 2014 at 04:39:38PM +0200, Michal Hocko wrote: > > > +#ifdef CONFIG_MEMCG_KMEM > > > + { > > > + .name = "kmem.limit_in_bytes", > > > + .private = MEMFILE_PRIVATE(_KMEM, RES_LIMIT), > > > + .write = mem_cgroup_write, > > > + .read_u64 = mem_cgroup_read_u64, > > > + }, > > > > Does it really make sense to have a separate limit for kmem only? > > IIRC, the reason we introduced this was that this memory is not > > reclaimable and so we need to limit it. > > > > But the opposite effect happened: because it's not reclaimable, the > > separate kmem limit is actually unusable for any values smaller than > > the overall memory limit: because there is no reclaim mechanism for > > that limit, once you hit it, it's over, there is nothing you can do > > anymore. The problem isn't so much unreclaimable memory, the problem > > is unreclaimable limits. > > > > If the global case produces memory pressure through kernel memory > > allocations, we reclaim page cache, anonymous pages, inodes, dentries > > etc. I think the same should happen for kmem: kmem should just be > > accounted and limited in the overall memory limit of a group, and when > > pressure arises, we go after anything that's reclaimable. > > Personally, I don't think there's much sense in having a separate knob > for kmem limit either. Until we have a user with a sane use case for it, > let's not propagate it to the new interface. What about fork-bomb forks protection? I thought that was the primary usecase for K < U? Or how can we handle that use case with a single limit? A special gfp flag to not trigger OOM path when called from some kmem charge paths? What about task_count or what was the name of the controller which was dropped and suggested to be replaced by kmem accounting? I can imagine that to be implemented by a separate K limit which would be roughtly stack_size * task_count + pillow for slab. -- Michal Hocko SUSE Labs