Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752861AbbB0QmU (ORCPT ); Fri, 27 Feb 2015 11:42:20 -0500 Received: from mail-ie0-f180.google.com ([209.85.223.180]:35641 "EHLO mail-ie0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbbB0QmS (ORCPT ); Fri, 27 Feb 2015 11:42:18 -0500 Message-ID: <54F09E62.8000007@gmail.com> Date: Fri, 27 Feb 2015 11:42:10 -0500 From: Austin S Hemmelgarn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tejun Heo , 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 References: <1424660891-12719-1-git-send-email-cyphar@cyphar.com> <20150227114940.GB3964@htj.duckdns.org> In-Reply-To: <20150227114940.GB3964@htj.duckdns.org> x-hashcash: 1:21:150227:tj@kernel.org::9e7a3387b0dc21628f32b321cf35d41b:baf6a0d6bc52597d x-hashcash: 1:21:150227:cyphar@cyphar.com::b21e29fb83fbe19d9f9002cd65d571fe:bb41cbcf247b3d4c x-hashcash: 1:21:150227:lizefan@huawei.com::da04dcf81967903dbf402b92cd704b0c:203f87cf6c8b2847 x-hashcash: 1:21:150227:mingo@redhat.com::481f4d3e6982fc6818f262a26c848a46:5a799b693eef974c x-hashcash: 1:21:150227:peterz@infradead.org::4030c5a17165c1ca263917d3d6e20e2:ab55eda160fc6c5c x-hashcash: 1:21:150227:richard@nod.at::890bc78ad8a2868492a7e1acca113d0b:ed1c2461f5ed73e7 x-hashcash: 1:21:150227:fweisbec@gmail.com::4d42c98feea7227a896ba5a919a0baf4:8f4b6f6c3227f58a x-hashcash: 1:21:150227:linux-kernel@vger.kernel.org::228217df033c261e2f5a331a68cd70ce:add54d13558ff7b x-hashcash: 1:21:150227:cgroups@vger.kernel.org::6b671477037ef35b8946cb45d6f2ae80:86dc8455f6606026 x-stampprotocols: hashcash:1:17;mbound:0:10:3000:5000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2198 Lines: 43 On 2015-02-27 06:49, Tejun Heo wrote: > 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. > Kernel memory consumption isn't the only valid reason to want to limit the number of processes in a cgroup. Limiting the number of processes is very useful to ensure that a program is working correctly (for example, the NTP daemon should (usually) have an _exact_ number of children if it is functioning correctly, and rpcbind shouldn't (AFAIK) ever have _any_ children), to prevent PID number exhaustion, to head off DoS attacks against forking network servers before they get to the point of causing kmem exhaustion, and to limit the number of processes in a cgroup that uses lots of kernel memory very infrequently. -- 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/