Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 15 Oct 2018 09:35:40 -0700
From:   Tejun Heo <tj@kernel.org>
To:     Waiman Long <longman@redhat.com>
Cc:     Li Zefan <lizefan@huawei.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, cgroups@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        kernel-team@fb.com, pjt@google.com, luto@amacapital.net,
        Mike Galbraith <efault@gmx.de>, torvalds@linux-foundation.org,
        Roman Gushchin <guro@fb.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Patrick Bellasi <patrick.bellasi@arm.com>
Subject: Re: [PATCH v13 00/11] cpuset: Enable cpuset controller in default
 hierarchy
Message-ID: <20181015163540.GQ270328@devbig004.ftw2.facebook.com>
References: <1539366951-8498-1-git-send-email-longman@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1539366951-8498-1-git-send-email-longman@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello, Waiman.

This looks great to me.  I have only one small nit in terms of
interface.  Currently, cpuset.partition file uses -1, 0, 1; however,
given that this is consistent with how cgroup.type behaves (something
can be set but may be invalid), I wonder whether using a similar
syntax would be more consistent.  e.g. sth like cpuset.type which
takes "normal" or "partition" and shows one of "normal", "partition"
and "partition invalid".  I'd be perfectly happy with that being a
follow-up patch.

Peter, does the patchset look good to you?  It does everything we want
it to in terms of sched domain partitioning and is compliant all
cgroup2 conventions.  If so, I'll apply the series to the cgroup devel
branch.

Thank you very much for the work and persistence!

-- 
tejun