Re: [PATCH RFC 0/2] add nproc cgroup subsystem
From: Austin S Hemmelgarn
Date: Fri Feb 27 2015 - 11:42:35 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/