From: Zefan Li <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Preeti U Murthy
<preeti-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
svaidy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
nacc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org,
bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH V2] cpuset: Add knob to make allowed masks hotplug invariant on legacy hierarchy
Date: Mon, 20 Apr 2015 11:28:09 +0800 [thread overview]
Message-ID: <55347249.1050301@huawei.com> (raw)
In-Reply-To: <552FA3B4.6080905-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 2015/4/16 19:57, Preeti U Murthy wrote:
> On 04/15/2015 10:06 PM, Serge E. Hallyn wrote:
>> On Wed, Apr 15, 2015 at 12:18:11PM -0400, Tejun Heo wrote:
>>> On Wed, Apr 15, 2015 at 11:15:35AM -0500, Serge E. Hallyn wrote:
>>>> The reason would be because it breaks "legacy" software. So that
>>>> would only matter if Preeti needs to run such software.
>>>
>>> Sure, I get that argument but this is changing how the contorller
>>> behaves in a major way.
>>
>> It is. My main counter to that would be that it is how cpusets
>> should always have worked :)
>>
>>> There are specifics which may make this
>>> particular case more justifiable but overall the combination of
>>> arguments is pretty weird.
>>
>> And becomes harder to reason about and review/maintain. I agree
>> there.
>>
>> From userspace, I suppose one approach (though note it is racy) to
>> solving this would be to have udev rules which
>>
>> . On cpu unplug, record all cgroups which were using that cpu
>> . on cpu plug, re-add the cpu to all recorded cgroups for that
>> cpu (if any), as well as to any cgroups marked (in some /etc
>> file) as using "all" or a percentage of all cpus.
>
> Yes this is the best way to move forward. But the stacks in userspace
> that manage cgroups need to each have such a daemon managing the cpusets
> like is pointed above. It would have been fair to expect them to do this
> except that this is one issue that userspace is expecting the kernel to
> handle. The side effects of this behavior of the legacy hierarchy is
> showing up in weird ways.
>
> Another approach as Tejun pointed is to switch over to the unified
> hierarchy. I can test this out (How do we mount specific controllers in
> the unified hierarchy Tejun? It does not allow any mount options today),
You just can't. All controllers are bound to unified hierarchy, except those
already mounted in the old way. That said, in the unified hierarchy you're able
to use cpuset only, so other controllers can still be mounted seperated.
Here is an example:
# use blkio cgroup in legacy hierachy
mount -t cgroup -o blkio xxx old/
# now mount the unified hierarchy
mount -t cgroup -o __DEVEL__sane_behavior xxx unified/
# use cpuset only
mkdir unified/cpuset
echo +cpuset > cgroup.subtree_control
# use memory cgroup in another legacy hierarchy
mount -t cgroup -o memory xxx old2/
You may refer to Documentation/cgroups/unified-hierarchy.txt
> but I don't think I can exhaustively test this out by myself across
> distros. So I am not confident of this approach.
>
> The last approach would be as Peter pointed, mimick the entire unified
> hierarchy through a mount option, similar to the SANE_BEHAVIOR option
> that was present earlier and was removed. Tejun ? Can we bring back that
> mount option ?
>
I don't think it's an option. We want users move to unified hierarchy.
WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan@huawei.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>, Tejun Heo <tj@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
<svaidy@linux.vnet.ibm.com>, <nacc@linux.vnet.ibm.com>,
<rjw@rjwysocki.net>, <linux-kernel@vger.kernel.org>,
<anton@samba.org>, <bharata@linux.vnet.ibm.com>,
<cgroups@vger.kernel.org>, <paulmck@linux.vnet.ibm.com>,
<mingo@kernel.org>
Subject: Re: [PATCH V2] cpuset: Add knob to make allowed masks hotplug invariant on legacy hierarchy
Date: Mon, 20 Apr 2015 11:28:09 +0800 [thread overview]
Message-ID: <55347249.1050301@huawei.com> (raw)
In-Reply-To: <552FA3B4.6080905@linux.vnet.ibm.com>
On 2015/4/16 19:57, Preeti U Murthy wrote:
> On 04/15/2015 10:06 PM, Serge E. Hallyn wrote:
>> On Wed, Apr 15, 2015 at 12:18:11PM -0400, Tejun Heo wrote:
>>> On Wed, Apr 15, 2015 at 11:15:35AM -0500, Serge E. Hallyn wrote:
>>>> The reason would be because it breaks "legacy" software. So that
>>>> would only matter if Preeti needs to run such software.
>>>
>>> Sure, I get that argument but this is changing how the contorller
>>> behaves in a major way.
>>
>> It is. My main counter to that would be that it is how cpusets
>> should always have worked :)
>>
>>> There are specifics which may make this
>>> particular case more justifiable but overall the combination of
>>> arguments is pretty weird.
>>
>> And becomes harder to reason about and review/maintain. I agree
>> there.
>>
>> From userspace, I suppose one approach (though note it is racy) to
>> solving this would be to have udev rules which
>>
>> . On cpu unplug, record all cgroups which were using that cpu
>> . on cpu plug, re-add the cpu to all recorded cgroups for that
>> cpu (if any), as well as to any cgroups marked (in some /etc
>> file) as using "all" or a percentage of all cpus.
>
> Yes this is the best way to move forward. But the stacks in userspace
> that manage cgroups need to each have such a daemon managing the cpusets
> like is pointed above. It would have been fair to expect them to do this
> except that this is one issue that userspace is expecting the kernel to
> handle. The side effects of this behavior of the legacy hierarchy is
> showing up in weird ways.
>
> Another approach as Tejun pointed is to switch over to the unified
> hierarchy. I can test this out (How do we mount specific controllers in
> the unified hierarchy Tejun? It does not allow any mount options today),
You just can't. All controllers are bound to unified hierarchy, except those
already mounted in the old way. That said, in the unified hierarchy you're able
to use cpuset only, so other controllers can still be mounted seperated.
Here is an example:
# use blkio cgroup in legacy hierachy
mount -t cgroup -o blkio xxx old/
# now mount the unified hierarchy
mount -t cgroup -o __DEVEL__sane_behavior xxx unified/
# use cpuset only
mkdir unified/cpuset
echo +cpuset > cgroup.subtree_control
# use memory cgroup in another legacy hierarchy
mount -t cgroup -o memory xxx old2/
You may refer to Documentation/cgroups/unified-hierarchy.txt
> but I don't think I can exhaustively test this out by myself across
> distros. So I am not confident of this approach.
>
> The last approach would be as Peter pointed, mimick the entire unified
> hierarchy through a mount option, similar to the SANE_BEHAVIOR option
> that was present earlier and was removed. Tejun ? Can we bring back that
> mount option ?
>
I don't think it's an option. We want users move to unified hierarchy.
next prev parent reply other threads:[~2015-04-20 3:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 14:11 [PATCH V2] cpuset: Add knob to make allowed masks hotplug invariant on legacy hierarchy Preeti U Murthy
2015-04-10 14:11 ` Preeti U Murthy
[not found] ` <20150410141118.11284.36206.stgit-KrPcdFQQmm2yUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2015-04-11 8:35 ` Peter Zijlstra
2015-04-11 8:35 ` Peter Zijlstra
2015-04-11 11:21 ` Preeti U Murthy
[not found] ` <552903BC.3050103-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-04-11 13:42 ` Peter Zijlstra
2015-04-11 13:42 ` Peter Zijlstra
[not found] ` <20150411083537.GR27490-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2015-04-13 7:01 ` Peter Zijlstra
2015-04-13 7:01 ` Peter Zijlstra
2015-04-13 8:25 ` Preeti U Murthy
[not found] ` <20150413070117.GX24151-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2015-04-13 12:16 ` Preeti U Murthy
2015-04-13 12:16 ` Preeti U Murthy
[not found] ` <552BB3A5.9060905-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-04-13 14:43 ` Peter Zijlstra
2015-04-13 14:43 ` Peter Zijlstra
[not found] ` <20150413144311.GF5029-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2015-04-15 11:40 ` Preeti U Murthy
2015-04-15 11:40 ` Preeti U Murthy
[not found] ` <552E4E41.3030008-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-04-15 15:03 ` Serge E. Hallyn
2015-04-15 15:03 ` Serge E. Hallyn
[not found] ` <20150415150302.GA25089-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-04-15 15:19 ` Peter Zijlstra
2015-04-15 15:19 ` Peter Zijlstra
[not found] ` <20150415151926.GS23123-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2015-04-15 15:30 ` Serge E. Hallyn
2015-04-15 15:30 ` Serge E. Hallyn
[not found] ` <20150415153035.GA25390-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-04-15 15:48 ` Tejun Heo
2015-04-15 15:48 ` Tejun Heo
[not found] ` <20150415154802.GB30337-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2015-04-15 16:15 ` Serge E. Hallyn
2015-04-15 16:15 ` Serge E. Hallyn
[not found] ` <20150415161534.GA25776-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-04-15 16:18 ` Tejun Heo
2015-04-15 16:18 ` Tejun Heo
2015-04-15 16:36 ` Serge E. Hallyn
2015-04-15 16:36 ` Serge E. Hallyn
2015-04-16 11:57 ` Preeti U Murthy
[not found] ` <552FA3B4.6080905-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-04-20 3:28 ` Zefan Li [this message]
2015-04-20 3:28 ` Zefan Li
2015-04-13 14:50 ` Tejun Heo
2015-04-13 14:50 ` Tejun Heo
2015-04-13 15:05 ` Peter Zijlstra
[not found] ` <20150413145052.GC2596-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2015-04-15 11:12 ` Preeti U Murthy
2015-04-15 11:12 ` Preeti U Murthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55347249.1050301@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
--cc=bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=nacc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=preeti-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
--cc=svaidy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.