[<prev] [next>] [day] [month] [year] [list]
Message-ID: <xhsmh1qmkr7pa.mognet@vschneid.remote.csb>
Date: Mon, 20 Feb 2023 09:45:37 +0000
From: Valentin Schneider <vschneid@...hat.com>
To: hupu <921889738@...com>, peterz@...radead.org
Cc: bristot@...hat.com, bsegall@...gle.com, dietmar.eggemann@....com,
ionela.voinescu@....com, juri.lelli@...hat.com,
len.brown@...el.com, linux-kernel@...r.kernel.org, mgorman@...e.de,
rafael.j.wysocki@...el.com, ravi.v.shankar@...el.com,
ricardo.neri-calderon@...ux.intel.com, ricardo.neri@...el.com,
rostedt@...dmis.org, srinivas.pandruvada@...ux.intel.com,
tim.c.chen@...el.com, tim.c.chen@...ux.intel.com,
vincent.guittot@...aro.org, x86@...nel.org, hupu@...o.com
Subject: Re: [PATCH v3 06/10] sched/fair: Use the prefer_sibling flag of the
current sched domain
On 20/02/23 15:22, hupu wrote:
> From: Peter Zijlstra <peterz@...radead.org>
>> Specifically, I'm thinking something in the degenerate area where it
>> looks if a given domain has equal depth children or so.
>
> By the way, in the last email you mentioned "the degenerate area". I can't understand what it means because of cultural differences. Does it refer to this scenario: sched_domain at the SMT layer is destroyed after an SMT thread goes offline, so mc_domain->child is NULL?
>
This references sched domain degeneration, cf. sd_parent_degenerate() and
sd_degenerate() in sched/topology.c
Sched domains are built following a layout described in
sched_domain_topology[], and depending on the actual CPU layout some
domains end up not being worth keeping (e.g. they only contain one CPU - we
need at least 2 to balance things), so we destroy (degenerate) them.
> hupu
Powered by blists - more mailing lists