From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-4.5 required=5.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 978B67D0DA for ; Tue, 20 Mar 2018 04:26:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751261AbeCTE0V (ORCPT ); Tue, 20 Mar 2018 00:26:21 -0400 Received: from mout.gmx.net ([212.227.15.18]:58959 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750991AbeCTE0U (ORCPT ); Tue, 20 Mar 2018 00:26:20 -0400 Received: from homer.simpson.net ([185.221.149.147]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrNIC-1eazpM387o-0137dZ; Tue, 20 Mar 2018 05:25:45 +0100 Message-ID: <1521519941.24215.2.camel@gmx.de> Subject: Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy From: Mike Galbraith To: Waiman Long , Tejun Heo Cc: Peter Zijlstra , Li Zefan , Johannes Weiner , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, torvalds@linux-foundation.org, Roman Gushchin Date: Tue, 20 Mar 2018 05:25:41 +0100 In-Reply-To: References: <1c3fe7b0-2600-c46d-1527-d3aaf024bb91@redhat.com> <1520619426.27998.18.camel@gmx.de> <55809fe4-98ba-5566-86ed-457acfef0e1c@redhat.com> <1520624424.27998.76.camel@gmx.de> <53de9683-01b7-bac4-8b70-dc1f93ede600@redhat.com> <20180309221736.GB5926@hirez.programming.kicks-ass.net> <1520653648.12749.20.camel@gmx.de> <20180314195711.GD2943022@devbig577.frc2.facebook.com> <1521082141.7100.1.camel@gmx.de> <20180319153413.GO2943022@devbig577.frc2.facebook.com> <1521492550.16869.1.camel@gmx.de> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VM1t3E95PZHGr+bysSU2O2GLczFVYwZWolEXaV0BPzLIKtLyH6K EcuUHpGyDWkJ3+RmlQScq0YrRHvyJkC0uZetDcR+oO6B/GUckgXn8PmuzBuJnKT6Rwzc8Ez rPwSP59szbnM4GRQy/UnA6en5vOb+ze2OBQHbBx9fLgxAk/CZElwoak5apE9Vc3jk2Nthdb 36v+ULUJCSxv6ARg4maeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:b2c1fpsRohQ=:lW50M50nFR6nJxupSmY2m4 G6fE0Ndr4NVxMtk+NrhFQsIr3AbOWTH7JrIV+TxQpihlMRlMWdnJMA5h1/KtZlT6fcuGvy6oK BcI6V1gMsqxF+Fjiau828d3aDE4GSLGKMxQjAugBWirGsHFzYr7n0egHFQBCe0HMAuXkVottW wyY1/1OwQ9/I82OYJPA32YZx7s8T4aj+MM/BcI8eeEaIOd/z4hxZF3QLkIwtcEz9GmXLE9tUm 6r8ZiW+gYaY6mRzAq4orE9epPGzRAhk6XiJH2jUopDRkis9kIFU6Ml7r8BEYK2Sc5Lvb5olPV fCZqjfk0hfsUTFT55AJS+n0HqXI5S4MRTRonSOqecJ6cQOAMw9Hb29SBMEH5RrTUPAPMFy+G/ S2XRONczGTRRaAPzDTqUNvT2zR4JsittJ4hb0c+o2J9DinzPhKpE0xEH0z7rb6KozKr7UY9rK W6SQGbB82nl4jscz1EijcyvPo1Ziktld1XJx9ZI65tjK/ewZ+DNFlkb8XS4aETnEZJzvMe7Pm mF/771ylaXYVMzuTl+cC3yaIZ+a6/M97OZzlSKPDXGrC5+TlyQnDCTBchtoEkEKH2jioGLlMy fj3OZbYSmZQ4ITYRryIJqZre/fumWm1BXjoqE4NYZG5tRFsSS2KoohQP9n677hQWWpDeJ3H/4 KWIsBoDAu2q1JntxDzRrCDTFobozpFvc5yX6Lj3nOmKDXJ7wNau1xNjM4p5/NqyS0t2sbuoYL 8NG9nVMe3CIqUEFVQF+WhUOohB6hT5E3eEVrvlK2Rh0gMbtgEL3Sr631vNXG7d7krDOXEDo0i hNXgE674OJ6d/Lmx06x8pMKDkg0SB5bvSWbAwmtKRTZgJmSqI4= Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, 2018-03-19 at 17:41 -0400, Waiman Long wrote: > On 03/19/2018 04:49 PM, Mike Galbraith wrote: > > On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote: > >> Hello, Mike. > >> > >> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote: > >>> Under the hood v2 details are entirely up to you. My input ends at > >>> please don't leave dynamic partitioning standing at the dock when v2 > >>> sails. > >> So, this isn't about implementation details but about what the > >> interface achieves - ie, what's the actual function? The only thing I > >> can see is blocking the entity which is configuring the hierarchy from > >> making certain configs. While that might be useful in some specific > >> use cases, it seems to miss the bar for becoming its own kernel > >> feature. After all, nothing prevents the same entity from clearing > >> the exlusive bit and making the said changes. > > Yes, privileged contexts can maliciously or stupidly step all over one > > other no matter what you do (finite resource), but oxymoron creation > > (CPUs simultaneously balanced and isolated) should be handled. If one > > context can allocate a set overlapping a set another context intends to > > or already has detached from scheduler domains, both are screwed. > > > > -Mike > > The allocations of CPUs to child cgroups should be controlled by the > parent cgroup. It is the parent's fault if some CPUs are in both > balanced and isolated cgroups. > > How about we don't allow turning off scheduling if the CPUs aren't > exclusive from the parent's perspective? So you can't create an isolated > cgroup if the CPUs aren't exclusive. Will this be a good enough compromise? Sure. The kernel need only ensure its own sanity. Userspace conflicts are more or less a non-issue. In practice, all players but one will have been constrained or eliminated prior to any partitioning. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html