From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Preeti U Murthy
<preeti-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: svaidy-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org,
lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant
Date: Wed, 8 Oct 2014 10:07:06 +0200 [thread overview]
Message-ID: <20141008080706.GC10832@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20141008070739.1170.33313.stgit-KrPcdFQQmm2yUtPGxGje5AC/G2K4zDHf@public.gmane.org>
On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
> There are two masks associated with cpusets. The cpus/mems_allowed
> and effective_cpus/mems. On the legacy hierarchy both these masks
> are consistent with each other. This is the intersection of their
> value and the currently active cpus. This means that we destroy the
> original values set in these masks on each cpu/mem hot unplug operation.
> As a consequence when we hot plug back the cpus/mems, the tasks
> no longer run on them and performance degrades, inspite of having
> resources to run on.
>
> This effect is not seen in the default hierarchy since the
> allowed and effective masks are distinctly maintained.
> allowed masks are never touched once configured and effective masks
> alone are hotplug variant.
>
> This patch replicates the above design even for the legacy hierarchy,
> so that:
>
> 1. Tasks always run on the cpus/memory nodes that they are allowed to run on
> as long as they are online. The allowed masks are hotplug invariant.
>
> 2. When all cpus/memory nodes in a cpuset are hot unplugged out, the tasks
> are moved to their nearest ancestor which has resources to run on.
>
> There were discussions earlier around this issue:
> https://lkml.org/lkml/2012/5/4/265
> http://thread.gmane.org/gmane.linux.kernel/1250097/focus=1252133
>
> The argument against making the allowed masks hotplug invariant was that
> hotplug is destructive and hence cpusets cannot expect to regain resources
> that have gone through a hotplug operation by the user.
>
> But on powerpc we do smt mode switch to suit the workload running.
> We therefore need to keep track of the original cpuset configuration
> so as to make use of them when they are back online due to a mode switch.
> Moreover there is no real harm in keeping the allowed masks invariant
> on hotplug since the effective masks will anyway keep track of the
> online cpus. In fact there are use cases which need the cpuset's
> original configuration to be retained. The v2 of cgroup design therefore
> does not overwrite this configuration.
>
I still completely hate all that.. It basically makes cpusets useless,
they no longer guarantee anything, it makes then an optional placement
hint instead.
You also break long standing behaviour.
Also, power is insane if it needs/uses hotplug for operational crap
like that.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: svaidy@linux.vnet.ibm.com, rjw@rjwysocki.net, lizefan@huawei.com,
anton@samba.org, tj@kernel.org, paulmck@linux.vnet.ibm.com,
mingo@kernel.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant
Date: Wed, 8 Oct 2014 10:07:06 +0200 [thread overview]
Message-ID: <20141008080706.GC10832@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20141008070739.1170.33313.stgit@preeti.in.ibm.com>
On Wed, Oct 08, 2014 at 12:37:40PM +0530, Preeti U Murthy wrote:
> There are two masks associated with cpusets. The cpus/mems_allowed
> and effective_cpus/mems. On the legacy hierarchy both these masks
> are consistent with each other. This is the intersection of their
> value and the currently active cpus. This means that we destroy the
> original values set in these masks on each cpu/mem hot unplug operation.
> As a consequence when we hot plug back the cpus/mems, the tasks
> no longer run on them and performance degrades, inspite of having
> resources to run on.
>
> This effect is not seen in the default hierarchy since the
> allowed and effective masks are distinctly maintained.
> allowed masks are never touched once configured and effective masks
> alone are hotplug variant.
>
> This patch replicates the above design even for the legacy hierarchy,
> so that:
>
> 1. Tasks always run on the cpus/memory nodes that they are allowed to run on
> as long as they are online. The allowed masks are hotplug invariant.
>
> 2. When all cpus/memory nodes in a cpuset are hot unplugged out, the tasks
> are moved to their nearest ancestor which has resources to run on.
>
> There were discussions earlier around this issue:
> https://lkml.org/lkml/2012/5/4/265
> http://thread.gmane.org/gmane.linux.kernel/1250097/focus=1252133
>
> The argument against making the allowed masks hotplug invariant was that
> hotplug is destructive and hence cpusets cannot expect to regain resources
> that have gone through a hotplug operation by the user.
>
> But on powerpc we do smt mode switch to suit the workload running.
> We therefore need to keep track of the original cpuset configuration
> so as to make use of them when they are back online due to a mode switch.
> Moreover there is no real harm in keeping the allowed masks invariant
> on hotplug since the effective masks will anyway keep track of the
> online cpus. In fact there are use cases which need the cpuset's
> original configuration to be retained. The v2 of cgroup design therefore
> does not overwrite this configuration.
>
I still completely hate all that.. It basically makes cpusets useless,
they no longer guarantee anything, it makes then an optional placement
hint instead.
You also break long standing behaviour.
Also, power is insane if it needs/uses hotplug for operational crap
like that.
next prev parent reply other threads:[~2014-10-08 8:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 7:07 [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant Preeti U Murthy
2014-10-08 7:07 ` Preeti U Murthy
[not found] ` <20141008070739.1170.33313.stgit-KrPcdFQQmm2yUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2014-10-08 8:07 ` Peter Zijlstra [this message]
2014-10-08 8:07 ` Peter Zijlstra
2014-10-08 9:37 ` Preeti U Murthy
2014-10-08 10:18 ` Peter Zijlstra
[not found] ` <20141008101828.GG10832-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-09 8:20 ` Preeti U Murthy
2014-10-09 8:20 ` Preeti U Murthy
[not found] ` <54364564.3090305-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-10-09 8:30 ` Peter Zijlstra
2014-10-09 8:30 ` Peter Zijlstra
2014-10-09 8:32 ` Peter Zijlstra
2014-10-09 8:32 ` Peter Zijlstra
2014-10-09 13:06 ` Tejun Heo
2014-10-09 13:06 ` Tejun Heo
[not found] ` <20141009130611.GA14387-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2014-10-09 13:47 ` Peter Zijlstra
2014-10-09 13:47 ` Peter Zijlstra
[not found] ` <20141009134758.GU10832-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2014-10-09 13:59 ` Tejun Heo
2014-10-09 13:59 ` Tejun Heo
2015-04-02 6:56 ` Preeti U Murthy
2015-04-02 6:56 ` Preeti U Murthy
[not found] ` <551CE820.9090900-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2015-04-06 17:47 ` Tejun Heo
2015-04-06 17:47 ` Tejun Heo
[not found] ` <20150406174735.GG10582-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2015-04-09 21:13 ` Serge E. Hallyn
2015-04-09 21:13 ` Serge E. Hallyn
[not found] ` <20150409211349.GA28729-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-04-10 14:14 ` Preeti U Murthy
2015-04-10 14:14 ` Preeti U Murthy
-- strict thread matches above, loose matches on Subject: below --
2014-10-08 14:54 Raghavendra KT
[not found] ` <CAC4Lta2AS6M5upg8n9Qu5+1pqCMF3j8_cYuLAS1DH9C_BQP0PA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-09 5:12 ` Preeti U Murthy
2014-10-09 5:12 ` Preeti U Murthy
[not found] ` <54361922.8070808-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-10-09 9:42 ` Raghavendra K T
2014-10-09 9:42 ` Raghavendra K T
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=20141008080706.GC10832@worktop.programming.kicks-ass.net \
--to=peterz-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=anton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=preeti-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@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.