Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753240AbdHXO40 convert rfc822-to-8bit (ORCPT ); Thu, 24 Aug 2017 10:56:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33636 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbdHXO4X (ORCPT ); Thu, 24 Aug 2017 10:56:23 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E810B285B5 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com Subject: Re: [PATCH] cpuset: Allow cpuset controller in default hierarchy To: Tejun Heo Cc: Li Zefan , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org References: <1503585611-13496-1-git-send-email-longman@redhat.com> <20170824144322.GP491396@devbig577.frc2.facebook.com> From: Waiman Long Organization: Red Hat Message-ID: <863b01d0-e724-dab6-258e-d5980f985938@redhat.com> Date: Thu, 24 Aug 2017 10:56:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170824144322.GP491396@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 24 Aug 2017 14:56:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1135 Lines: 28 On 08/24/2017 10:43 AM, Tejun Heo wrote: > Hello, Waiman. > > On Thu, Aug 24, 2017 at 10:40:11AM -0400, Waiman Long wrote: >> Given the fact that thread mode is now queued for 4.14, it is now >> time to enable cpuset to be used in the default hierarchy (cgroup v2) >> as it is clearly threaded. > I'm not sure we want things like exclusive settings in v2 as it > directly violates basic hierarchy rules (a sibling shouldn't be able > to affect what another sibling can or can't do). We need to think > more about what should be exposed in v2. Thank for the quick response. The main reason for sending out this patch is to figure out what exactly is in your mind before enabling cpuset in v2. >From my point of view, the exclusive setting makes cpuset behave more like a resource domain that a resource allocated to one cgroup won't be available for another cgroup. So we can argue it both ways whether it violates the basic hierarchy rules or not. I will be in the Plumbers Conference next month and we can talk more about this. My goal is to make cgroup v2 ready for prime time hopefully by the end of the year. Cheers, Longman