From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753389AbbCAEqh (ORCPT ); Sat, 28 Feb 2015 23:46:37 -0500 Received: from mail-la0-f47.google.com ([209.85.215.47]:37280 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752462AbbCAEqf (ORCPT ); Sat, 28 Feb 2015 23:46:35 -0500 MIME-Version: 1.0 In-Reply-To: <20150228225036.GA4597@htj.duckdns.org> References: <20150227114940.GB3964@htj.duckdns.org> <54F09E62.8000007@gmail.com> <20150227170640.GK3964@htj.duckdns.org> <20150227174503.GM3964@htj.duckdns.org> <20150227214904.GQ3964@htj.duckdns.org> <20150228165706.GS3964@htj.duckdns.org> <20150228225036.GA4597@htj.duckdns.org> From: Tim Hockin Date: Sat, 28 Feb 2015 20:46:13 -0800 X-Google-Sender-Auth: si1Db79CKgzYJDAkmv4FNasKX1c Message-ID: Subject: Re: [PATCH RFC 0/2] add nproc cgroup subsystem To: Tejun Heo Cc: Austin S Hemmelgarn , Li Zefan , Peter Zijlstra , Frederic Weisbecker , "linux-kernel@vger.kernel.org" , Aleksa Sarai , Cgroups , mingo , richard Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Feb 28, 2015 2:50 PM, "Tejun Heo" wrote: > > On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote: > > Wow, so much anger. I'm not even sure how to respond, so I'll just > > say this and sign off. All I want is a better, friendlier, more > > useful system overall. We clearly have different ways of looking at > > the problem. > > Can you communicate anything w/o passive aggression? If you have a > technical point, just state that. Can you at least agree that we > shouldn't be making design decisions based on 16bit pid_t? Hmm, I have screwed this thread up, I think. I've made some remarks that did not come through with the proper tongue-in-cheek slant. I'm not being passive aggressive - we DO look at this problem differently. OF COURSE we should not make decisions based on ancient artifacts of history. My point was that there are secondary considerations here - PIDs are more than just the memory that backs them. They _ARE_ a constrained resource, and you shouldn't assume the constraint is just physical memory. It is a piece of policy that is outside the control of the kernel proper - we handed those keys to userspace along time ago. Given that, I believe and have believed that the solution should model the problem as the user perceives it - limiting PIDs - rather than attaching to a solution-by-proxy. Yes a solution here partially overlaps with kmemcg, but I don't think that is a significant problem. They are different policies governing behavior that may result in the same condition, but for very different reasons. I do not think that is particularly bad for overall comprehension, and I think the fact that this popped up yet again indicates the existence of some nugget of user experience that is worth paying consideration to. I appreciate your promised consideration through a slightly refocused lens. I will go back to my cave and do something I hope is more productive and less antagonistic. I did not mean to bring out so much vitriol. Tim