Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754695AbdLVAQC (ORCPT ); Thu, 21 Dec 2017 19:16:02 -0500 Received: from mail-qk0-f175.google.com ([209.85.220.175]:39069 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148AbdLVAP6 (ORCPT ); Thu, 21 Dec 2017 19:15:58 -0500 X-Google-Smtp-Source: ACJfBosZWqcCSkQ1nEPxSdr24Q9pnp4BYbfhxRVY9z+xnY5F+tyxE+/K2iguh4J4S7nH5B6Dl81L0A== Date: Thu, 21 Dec 2017 16:15:54 -0800 From: Tejun Heo To: "Michael Kerrisk (man-pages)" Cc: Peter Zijlstra , longman@redhat.com, lkml , linux-man , "open list:CONTROL GROUP (CGROUP)" Subject: Re: Cgroups v2 thread mode "domain invalid" state Message-ID: <20171222001554.GH1084507@devbig577.frc2.facebook.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1488 Lines: 37 Hello, On Wed, Dec 20, 2017 at 09:32:04PM +0100, Michael Kerrisk (man-pages) wrote: > I did find the July 2017 mail thread > "[PATCH 5/6] cgroup: implement cgroup v2 thread support" > (https://marc.info/?t=150025735500001&r=1&w=2) > where this cgroup type was discussed, but I must admit that I still > don't get it. Instead of converting cgroups under a threaded subtree > to "domain invalid" type, why can't they just be turned straight into > "threaded" type? > > I guess another way of asking this question is: what possibilities > does manually switching each "domain invalid" cgroup to "threaded" > allow that wouldn't be allowed by immediately making all of the > cgroups in a threaded subtree "threaded"? IIRC, there were two reasons. (Writing from memory, so I might not be completely accurate.) * Consistency w/ the cgroups right under the root cgroup. Because they can be both domains and threadroots, we can't switch the children over to thread mode automatically. Doing that for cgroups further down in the hierarchy would be really inconsistent. * Possible extension to threadmode. If we figure out how to do mixed mode further down in the hierarchy (and if there are actual use cases which require that), automatically switching would be really confusing. The invalid state while not the most convenient is straight forward (only the operations which are explicitly asked are performed) and keeps the door open for future changes. Thanks. -- tejun