Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752259AbbB1J0j (ORCPT ); Sat, 28 Feb 2015 04:26:39 -0500 Received: from mail-ig0-f177.google.com ([209.85.213.177]:38933 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750885AbbB1J0f (ORCPT ); Sat, 28 Feb 2015 04:26:35 -0500 MIME-Version: 1.0 X-Originating-IP: [122.106.150.15] In-Reply-To: <54F0BC51.4050506@gmail.com> References: <1424660891-12719-1-git-send-email-cyphar@cyphar.com> <20150227114940.GB3964@htj.duckdns.org> <54F09E62.8000007@gmail.com> <20150227170640.GK3964@htj.duckdns.org> <54F0BC51.4050506@gmail.com> Date: Sat, 28 Feb 2015 20:26:34 +1100 Message-ID: Subject: Re: [PATCH RFC 0/2] add nproc cgroup subsystem From: Aleksa Sarai To: Austin S Hemmelgarn Cc: Tejun Heo , lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org, richard@nod.at, =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3023 Lines: 54 > I wouldn't think that preventing PID exhaustion would be all that much of a > niche case, it's fully possible for it to happen without using excessive > amounts of kernel memory (think about BIG server systems with terabytes of > memory running (arguably poorly written) forking servers that handle tens of > thousands of client requests per second, each lasting multiple tens of > seconds), and not necessarily as trivial as you might think to handle sanely > (especially if you want callbacks when the limits get hit). > As far as being trivial to achieve, I'm assuming you are referring to rlimit > and PAM's limits module, both of which have their own issues. Using > pam_limits.so to limit processes isn't trivial because it requires calling > through PAM to begin with, which almost no software that isn't login related > does, and rlimits are tricky to set up properly with the granularity that > having a cgroup would provide. I just want to quickly echo my support for this statement. Process IDs aren't limited by kernel memory, they're a hard-set limit. Thus they are a resource like other global resources (open files, etc). Now, while you can argue that it is possible to limit the amount of *effective* processes you can use in a cgroup through kmemcg (by limiting the amount of memory spent in storing task_struct data) -- that isn't limiting the usage of the *actual* resource (the fact you're limiting the number of PIDs is little more than a by-product). Also, If it wasn't an actual resource then why is RLIMIT_NPROC a thing? To me, that indicates that PID limiting not an esoteric usecase and it should be possible to use the Linux kernel's home-grown accounting system to limit the number of PIDs in a cgroup. Otherwise you're stuck in a weird world where you *can* limit the number of processes in a process tree but *not* the number of processes in a cgroup. >> In general, I'm pretty strongly against adding controllers for things >> which aren't fundamental resources in the system. What's next? Open >> files? Pipe buffer? Number of flocks? Number of session leaders or >> program groups? >> > PID's are a fundamental resource, you run out and it's an only marginally > better situation than OOM, namely, if you don't already have a shell open > which has kill builtin (because you can't fork), or have some other reliable > way to terminate processes without forking, you are stuck either waiting for > the problem to resolve itself, or have to reset the system. I couldn't agree more. PIDs are a fundamental resource because there is a hard limit on the amount of PIDs you can have in any one system. Once you've exhausted that limit, there's not much you can do apart from doing the SYSRQ dance. -- Aleksa Sarai (cyphar) www.cyphar.com -- 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/