From: Juri Lelli <juri.lelli@redhat.com>
To: Waiman Long <longman@redhat.com>
Cc: Tejun Heo <tj@kernel.org>, 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>
Subject: Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus
Date: Tue, 29 May 2018 08:27:03 +0200 [thread overview]
Message-ID: <20180529062703.GA8985@localhost.localdomain> (raw)
In-Reply-To: <8e610b98-970c-a309-5821-fc8e6aca892f@redhat.com>
On 28/05/18 21:24, Waiman Long wrote:
> On 05/28/2018 09:12 PM, Waiman Long wrote:
> > On 05/24/2018 06:28 AM, Juri Lelli wrote:
> >> On 17/05/18 16:55, Waiman Long wrote:
> >>
> >> [...]
> >>
> >>> @@ -849,7 +860,12 @@ static void rebuild_sched_domains_locked(void)
> >>> * passing doms with offlined cpu to partition_sched_domains().
> >>> * Anyways, hotplug work item will rebuild sched domains.
> >>> */
> >>> - if (!cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
> >>> + if (!top_cpuset.isolation_count &&
> >>> + !cpumask_equal(top_cpuset.effective_cpus, cpu_active_mask))
> >>> + goto out;
> >>> +
> >>> + if (top_cpuset.isolation_count &&
> >>> + !cpumask_subset(top_cpuset.effective_cpus, cpu_active_mask))
> >>> goto out;
> >> Do we cover the case in which hotplug removed one of the isolated cpus
> >> from cpu_active_mask?
> > Yes, you are right. That is the remnant of my original patch that allows
> > only one isolated_cpus at root. Thanks for spotting that.
>
> I am sorry. I would like to take it back my previous comment. The code
> above looks for inconsistency in the state of the effective_cpus mask to
> find out if it is racing with a hotplug event. If it is, we can skip the
> domain generation as the hotplug event will do that too. The checks are
> still valid with the current patchset. So I don't think we need to make
> any change here.
Yes, these checks are valid, but don't we also need to check for hotplug
races w.r.t. isolated CPUs (of some other sub domain)?
next prev parent reply other threads:[~2018-05-29 6:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 20:55 [PATCH v8 0/6] Enable cpuset controller in default hierarchy Waiman Long
2018-05-17 20:55 ` [PATCH v8 1/6] cpuset: " Waiman Long
2018-05-21 11:55 ` Patrick Bellasi
2018-05-21 13:55 ` Waiman Long
2018-05-21 15:09 ` Patrick Bellasi
2018-05-21 16:10 ` Waiman Long
2018-05-17 20:55 ` [PATCH v8 2/6] cpuset: Add new v2 cpuset.sched.domain flag Waiman Long
2018-05-22 12:57 ` Juri Lelli
2018-05-22 13:20 ` Waiman Long
2018-05-29 0:55 ` Waiman Long
2018-05-24 15:41 ` Peter Zijlstra
2018-05-24 18:53 ` Waiman Long
2018-05-25 7:15 ` Peter Zijlstra
2018-05-17 20:55 ` [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2 Waiman Long
2018-05-24 14:36 ` Juri Lelli
2018-05-24 15:09 ` Waiman Long
2018-05-24 15:16 ` Juri Lelli
2018-05-24 15:22 ` Waiman Long
2018-05-25 9:40 ` Patrick Bellasi
2018-05-25 14:45 ` Waiman Long
2018-05-24 15:43 ` Peter Zijlstra
2018-05-24 18:55 ` Waiman Long
2018-05-28 12:45 ` Peter Zijlstra
2018-05-28 18:31 ` Waiman Long
2018-05-17 20:55 ` [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus Waiman Long
2018-05-23 17:34 ` Patrick Bellasi
2018-05-23 20:18 ` Waiman Long
2018-05-24 9:04 ` Patrick Bellasi
2018-05-24 10:39 ` Juri Lelli
2018-05-25 10:31 ` Patrick Bellasi
2018-05-25 12:52 ` Juri Lelli
2018-05-24 10:28 ` Juri Lelli
2018-05-29 1:12 ` Waiman Long
2018-05-29 1:24 ` Waiman Long
2018-05-29 6:27 ` Juri Lelli [this message]
2018-05-29 12:40 ` Waiman Long
2018-05-29 13:12 ` Juri Lelli
2018-05-17 20:55 ` [PATCH v8 5/6] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root Waiman Long
2018-05-17 20:55 ` [PATCH v8 6/6] cpuset: Allow reporting of sched domain generation info Waiman Long
2018-05-22 13:53 ` Juri Lelli
2018-05-29 1:04 ` Waiman Long
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=20180529062703.GA8985@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=efault@gmx.de \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=longman@redhat.com \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).