From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by kanga.kvack.org (Postfix) with ESMTP id 7D3EA6B0036 for ; Mon, 21 Jul 2014 05:07:29 -0400 (EDT) Received: by mail-we0-f174.google.com with SMTP id x48so7211783wes.19 for ; Mon, 21 Jul 2014 02:07:28 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id wr4si26724802wjb.15.2014.07.21.02.07.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 02:07:27 -0700 (PDT) Date: Mon, 21 Jul 2014 11:07:24 +0200 From: Michal Hocko 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> Sender: owner-linux-mm@kvack.org List-ID: 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 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org