From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753942AbbCBNNb (ORCPT ); Mon, 2 Mar 2015 08:13:31 -0500 Received: from mail-ig0-f175.google.com ([209.85.213.175]:41188 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbbCBNN2 (ORCPT ); Mon, 2 Mar 2015 08:13:28 -0500 Message-ID: <54F461F3.3030903@gmail.com> Date: Mon, 02 Mar 2015 08:13:23 -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 , Tim Hockin CC: Frederic Weisbecker , lizefan@huawei.com, richard@nod.at, mingo@redhat.com, Aleksa Sarai , cgroups@vger.kernel.org, peterz@infradead.org, linux-kernel@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> <54F09E62.8000007@gmail.com> <20150227170640.GK3964@htj.duckdns.org> <54F0BC51.4050506@gmail.com> <20150228115926.GA1005@htj.duckdns.org> <20150228164353.GR3964@htj.duckdns.org> In-Reply-To: <20150228164353.GR3964@htj.duckdns.org> x-hashcash: 1:21:150302:tj@kernel.org::584f8c32e508dc1842cf5a2adcfa7033:28ae6135af6c17d3 x-hashcash: 1:21:150302:thockin@hockin.org::15df921c2645d31f632f0468a1e122b:64d57190212a911c x-hashcash: 1:21:150302:fweisbec@gmail.com::766c598ccb4075d9f9da4729f70f4745:49f2072c2646875a x-hashcash: 1:21:150302:lizefan@huawei.com::1c8a9ab85443046529ef1366844ab7d2:8b2da02d210b9599 x-hashcash: 1:21:150302:richard@nod.at::b5f3e8c45fdaaf53d6845d9bb85b4be8:845f880a79f5b0f x-hashcash: 1:21:150302:mingo@redhat.com::fc2f06d83cfea9a4cacb90e6c8fc364d:cbc3e37f5e1ef5cb x-hashcash: 1:21:150302:cyphar@cyphar.com::b5d28e4dbffcf0041c499432c041190f:ff1eb0db10dccb81 x-hashcash: 1:21:150302:cgroups@vger.kernel.org::e016c18db48810637f6b2a5f751471cf:a4ec26ed8b6825df x-hashcash: 1:21:150302:peterz@infradead.org::9e2e07477e7a32b2b9dea035901b93e:c93d18aa6a74863a x-hashcash: 1:21:150302:linux-kernel@vger.kernel.org::77a8d7df3ababbca47271b6a1986c178:8d89ed6ec08822da 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 On 2015-02-28 11:43, Tejun Heo wrote: > Hello, Tim. > > On Sat, Feb 28, 2015 at 08:38:07AM -0800, Tim Hockin wrote: >> I know there is not much concern for legacy-system problems, but it is >> worth adding this case - there are systems that limit PIDs for other >> reasons, eg broken infrastructure that assumes PIDs fit in a short int, >> hypothetically. Given such a system, PIDs become precious and limiting >> them per job is important. >> >> My main point being that there are less obvious considerations in play than >> just memory usage. > > Sure, there are those cases but it'd be unwise to hinge long term > decisions on them. It's hard to even argue 16bit pid in legacy code > as a significant contributing factor at this point. At any rate, it > seems that pid is a global resource which needs to be provisioned for > reasonable isolation which is a good reason to consider controlling it > via cgroups. If 16-bit PID's aren't a concern anymore, then why do we still default to treating it like a 16-bit signed int (the default for /proc/sys/kernel/pid_max is 32768)?