From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752210AbdGVNoG (ORCPT ); Sat, 22 Jul 2017 09:44:06 -0400 Received: from mail-qt0-f182.google.com ([209.85.216.182]:33272 "EHLO mail-qt0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751329AbdGVNoE (ORCPT ); Sat, 22 Jul 2017 09:44:04 -0400 Date: Sat, 22 Jul 2017 09:43:58 -0400 From: Tejun Heo To: Waiman Long Cc: Li Zefan , Johannes Weiner , Peter Zijlstra , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de, torvalds@linux-foundation.org, guro@fb.com Subject: Re: [PATCH v2 1/4] cgroup: Child cgroup creation not allowed on invalid domain Message-ID: <20170722134358.GB3329631@devbig577.frc2.facebook.com> References: <1500669293-21792-1-git-send-email-longman@redhat.com> <1500669293-21792-2-git-send-email-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1500669293-21792-2-git-send-email-longman@redhat.com> 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 Hello, Waiman. On Fri, Jul 21, 2017 at 04:34:50PM -0400, Waiman Long wrote: > When thread mode is used, it is possible that some cgroups may be > in an invalid state. Currently users may not be aware that they are > invalid until they try to migrate tasks over. This patch disallows > child cgroup creation on invalid domain. This adds one more failure > point in reminding users that they are dealing with invalid domains. > It also minimizes the number of invalid domains outstanding as much > as possible. It's a bit inconsistent because we can reach the same forbidden state by turning a sibling cgroup threaded. Please consider the following. A / \ B C \ D Let's say all are domains and we make B threaded. A becomes the threaded domain, C and D become invalid, which is the configuration you're trying to prevent. We can either enabling threaded on B too or relax type modifications further so that people can make C threaded which makes sense given that that would lead to a topology which has to supported anyway (if C were threaded before D was created, it'd look the same). So, I'm leaning more towards relaxing restrictions and tightening it, and given that we have to expose invalid state anyway, I think there's actual benefit in doing so as it gives more flexibility while building the hierarchy. Thanks. -- tejun