[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191115171807.GH19372@blackbody.suse.cz>
Date: Fri, 15 Nov 2019 18:18:07 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Valentin Schneider <valentin.schneider@....com>
Cc: linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
lizefan@...wei.com, tj@...nel.org, hannes@...xchg.org,
mingo@...nel.org, peterz@...radead.org, vincent.guittot@...aro.org,
Dietmar.Eggemann@....com, morten.rasmussen@....com,
qperret@...gle.com
Subject: Re: [PATCH v2] sched/topology, cpuset: Account for housekeeping CPUs
to avoid empty cpumasks
Hello.
On Thu, Nov 14, 2019 at 04:03:50PM +0000, Valentin Schneider <valentin.schneider@....com> wrote:
> Michal, could I nag you for a reviewed-by? I'd feel a bit more confident
> with any sort of approval from folks who actually do use cpusets.
TL;DR I played with the v5.4-rc6 _without_ this fixup and I conclude it
unnecessary (IOW my previous theoretical observation was wrong).
The original problem is non-issue with v2 cpuset controller, because
effective_cpus are never empty. isolcpus doesn't take out cpuset CPUs,
hotplug does. In the case, no online CPU remains in the cpuset, it
inherits ancestor's non-empty cpuset.
I reproduced the problem with v1 (before your fix). However, in v1
effective == allowed (we're destructive and overwrite allowed on
hotunplug) and we already check the emptiness of
cpumask_intersects(cp->cpus_allowed, housekeeping_cpumask(HK_FLAG_DOMAIN)
few lines higher. I.e. the fixup adds redundant check against the empty
sched domain production.
Sorry for the noise and HTH,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists