[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YG2hRBnf16raGy63@hirez.programming.kicks-ass.net>
Date: Wed, 7 Apr 2021 14:10:44 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Rik van Riel <riel@...riel.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Kernel Team <kernel-team@...com>,
Ingo Molnar <mingo@...nel.org>,
Valentin Schneider <valentin.schneider@....com>
Subject: Re: [PATCH v3] sched/fair: bring back select_idle_smt, but
differently
On Wed, Apr 07, 2021 at 11:47:17AM +0100, Mel Gorman wrote:
> Ok, cpusets do split domains. I can't imagine the logic of splitting SMT
> siblings across cpusets but if it's possible, it has to be checked and
> protecting that with cpusets_enabled() would be a little overkill and
> possibly miss some other corner case :(
Quite. The logic is that some people can't be arsed to look at how the
topology is enumerated and simply split logical CPUs by a random number.
Imagine we have 4 cores, with 2 threads each, for 8 logical CPUs.
Suppose you want a partition of 6 'cpus' and 2 spares. Hoping for a 3:1
core split.
If things are enumerated like: core0{smt0, smt1}, core1{smt0, smt1} ...
then 0-5 will get you 3 whole cores.
If OTOH things are enumerated like: smt0{core0, core1, core2, core3},
smt1{...} then 0-5 will get you the loonie side of the moon.
Funny thing is that x86 can iterate either way depending on how the BIOS
monkey filled out the tables.
Powered by blists - more mailing lists