Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752751AbbB0Ltq (ORCPT ); Fri, 27 Feb 2015 06:49:46 -0500 Received: from mail-qa0-f51.google.com ([209.85.216.51]:33907 "EHLO mail-qa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750777AbbB0Ltp (ORCPT ); Fri, 27 Feb 2015 06:49:45 -0500 Date: Fri, 27 Feb 2015 06:49:40 -0500 From: Tejun Heo To: Aleksa Sarai Cc: lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org, richard@nod.at, fweisbec@gmail.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH RFC 0/2] add nproc cgroup subsystem Message-ID: <20150227114940.GB3964@htj.duckdns.org> References: <1424660891-12719-1-git-send-email-cyphar@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424660891-12719-1-git-send-email-cyphar@cyphar.com> 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 Content-Length: 1510 Lines: 35 Hello, On Mon, Feb 23, 2015 at 02:08:09PM +1100, Aleksa Sarai wrote: > The current state of resource limitation for the number of open > processes (as well as the number of open file descriptors) requires you > to use setrlimit(2), which means that you are limited to resource > limiting process trees rather than resource limiting cgroups (which is > the point of cgroups). > > There was a patch to implement this in 2011[1], but that was rejected > because it implemented a general-purpose rlimit subsystem -- which meant > that you couldn't control distinct resource limits in different > heirarchies. This patch implements a resource controller *specifically* > for the number of processes in a cgroup, overcoming this issue. > > There has been a similar attempt to implement a resource controller for > the number of open file descriptors[2], which has not been merged > becasue the reasons were dubious. Merely from a "sane interface" > perspective, it should be possible to utilise cgroups to do such > rudimentary resource management (which currently only exists for process > trees). This isn't a proper resource to control. kmemcg just grew proper reclaim support and will be useable to control kernel side of memory consumption. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/