From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754879AbcIJIzF (ORCPT ); Sat, 10 Sep 2016 04:55:05 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35753 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751816AbcIJIzB (ORCPT ); Sat, 10 Sep 2016 04:55:01 -0400 Message-ID: <1473497697.3857.161.camel@gmail.com> Subject: Re: [Documentation] State of CPU controller in cgroup v2 From: Mike Galbraith To: Tejun Heo , Andy Lutomirski Cc: Ingo Molnar , "linux-kernel@vger.kernel.org" , kernel-team@fb.com, "open list:CONTROL GROUP (CGROUP)" , Andrew Morton , Paul Turner , Li Zefan , Linux API , Peter Zijlstra , Johannes Weiner , Linus Torvalds Date: Sat, 10 Sep 2016 10:54:57 +0200 In-Reply-To: <20160909225747.GA30105@mtj.duckdns.org> References: <20160820155659.GA16906@mtj.duckdns.org> <20160829222048.GH28713@mtj.duckdns.org> <20160831173251.GY12660@htj.duckdns.org> <20160831210754.GZ12660@htj.duckdns.org> <20160903220526.GA20784@mtj.duckdns.org> <20160909225747.GA30105@mtj.duckdns.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > But, whatever, let's go there: Given the arguments that I laid out for > the no-internal-tasks rule, how does the problem seem fixable through > relaxing the constraint? Well, for one thing, cpusets would cease to leak CPUs. With the no -internal-tasks constraint, no task can acquire affinity of exclusive set A if set B is an exclusive subset thereof, as there is one and only one spot where the affinity of set A exists: in the forbidden set A. Relaxing no-internal-tasks would fix that, but without also relaxing the process-only rule, cpusets would remain useless for the purpose for which it was created. After all, it doesn't do much good to use the one and only dynamic partitioning tool to partition a box if you cannot subsequently place your tasks/threads properly therein. > What people do now with cgroup inside an application is extremely > limited. Because there is no proper support for it, each use case has > to craft up a dedicated custom setup which is all but guaranteed to be > incompatible with what someone else would come up for another > application. Everybody is in "this is mine, I control the entire > system" mindset, which is fine for those specific setups but > deterimental to making it widely available and useful. IMO, the problem with that making it available to the huddled masses bit is that it is a completely unrealistic fantasy. Can hordes of programs really autonomously carve up a single set of resources? I do not believe they can. The system agent cannot autonomously do so either. Intimate knowledge of local requirements is not optional, it is a prerequisite to sound decision making. You have to have a well defined need before it makes any sense to turn these things on, they are not free, and impact is global. -Mike