From: dietmar.eggemann@arm.com (Dietmar Eggemann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 5/5] sched: ARM: create a dedicated scheduler topology table
Date: Fri, 25 Apr 2014 16:55:49 +0100 [thread overview]
Message-ID: <535A8585.6030103@arm.com> (raw)
In-Reply-To: <CAKfTPtAq8PXS-n7A0W6ESe08m-6O3u84BcY3==+-0+63+uca9g@mail.gmail.com>
On 25/04/14 08:45, Vincent Guittot wrote:
[...]
>>
>> Back than I had
>> CPU0: cpu_corepower_mask=0-1
>> CPU2: cpu_corepower_mask=2
>> so for GMC level the cpumasks are inconsistent across CPUs and it worked.
>
> The example above is consistent because CPU2 mask and CPU0 mask are
> fully exclusive
OK, got it now. The cpu mask functions on an sd level can return
different (but then exclusive) cpu masks or they all return the same cpu
mask (DIE level in example). Like you said we still have to respect the
topology of the system.
This essentially excludes the DIE level (i.e. the sd level which spawns
all CPUs) from playing this 'sd level folding via sd degenerate' game
for a system which specifies FORCE_SD_OVERLAP to false or don't use this
SDTL_OVERLAP tl flag.
>
> so
> CPU0: cpu_corepower_mask=0-1
> CPU2: cpu_corepower_mask=2
> are consistent
>
> CPU0: cpu_corepower_mask=0-2
> CPU2: cpu_corepower_mask=0-2
> are also consistent
>
> but
>
> CPU0: cpu_corepower_mask=0-1
> CPU2: cpu_corepower_mask=0-2
> are not consistent
>
> and your example uses the last configuration
>
> To be more precise, the rule above applies on default SDT definition
> but the flag SD_OVERLAP enables such kind of overlap between group.
> Have you tried it ?
Setting FORCE_SD_OVERLAP indeed changes the scenario a bit (we're now
using build_overlap_sched_groups() instead of build_sched_groups()). It
looks better, but the groups for CPU0/1 in DIE level are wrong (to get
so far I still have to comment out the check that 'if cpu_map is equal
to sd span of sd then break' in build_sched_domains() though).
dmesg snippet:
CPU0 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 0 1
domain 1: span 0-4 level DIE
groups: 0-4 (cpu_power = 5120) 0-1 (cpu_power = 2048) <-- error !!!
CPU1 attaching sched-domain:
domain 0: span 0-1 level MC
groups: 1 0
domain 1: span 0-4 level DIE
groups: 0-1 (cpu_power = 2048) 0-4 (cpu_power = 5120) <-- error !!!
CPU2 attaching sched-domain:
domain 0: span 2-4 level GMC
groups: 2 3 4
domain 1: span 0-4 level GDIE
groups: 2-4 (cpu_power = 3072) 0-1 (cpu_power = 2048)
...
The feature I'm currently working on is to add sd energy information to
sd levels of the sd topology level table. I essentially added another
column of sd energy related func ptr's (next to the flags related one)
and wanted to use 'sd level folding via sd degenerate' in MC and DIE
level to have different sd energy information per CPU.
In any case, this dependency to FORCE_SD_OVERLAP would be less then nice
for this feature though :-( A way out would be a 'int cpu' parameter but
we already discussed this back then for the flag function.
Thanks,
-- Dietmar
>
> Vincent
>
[...]
next prev parent reply other threads:[~2014-04-25 15:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 9:44 [PATCH v4 0/5] rework sched_domain topology description Vincent Guittot
2014-04-11 9:44 ` [PATCH v4 1/5] sched: rework of sched_domain topology definition Vincent Guittot
2014-04-18 10:56 ` Peter Zijlstra
2014-04-18 11:34 ` [PATCH] fix: " Vincent Guittot
2014-04-18 11:39 ` Peter Zijlstra
2014-04-18 11:34 ` [PATCH v4 1/5] " Vincent Guittot
2014-04-11 9:44 ` [PATCH v4 2/5] sched: s390: create a dedicated topology table Vincent Guittot
2014-04-11 9:44 ` [PATCH v4 3/5] sched: powerpc: " Vincent Guittot
2014-04-11 9:44 ` [PATCH v4 4/5] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain Vincent Guittot
2014-04-18 10:58 ` Peter Zijlstra
2014-04-18 11:54 ` [PATCH] fix: sched: rework of sched_domain topology definition Vincent Guittot
2014-04-18 11:54 ` [PATCH v4 4/5] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain Vincent Guittot
2014-04-11 9:44 ` [PATCH v4 5/5] sched: ARM: create a dedicated scheduler topology table Vincent Guittot
2014-04-23 11:46 ` Dietmar Eggemann
2014-04-23 14:46 ` Vincent Guittot
2014-04-23 15:26 ` Dietmar Eggemann
2014-04-24 7:30 ` Vincent Guittot
2014-04-24 12:48 ` Dietmar Eggemann
2014-04-25 7:45 ` Vincent Guittot
2014-04-25 15:55 ` Dietmar Eggemann [this message]
2014-04-25 16:04 ` Peter Zijlstra
2014-04-25 16:05 ` Peter Zijlstra
2014-04-12 12:56 ` [PATCH v4 0/5] rework sched_domain topology description Dietmar Eggemann
2014-04-14 7:29 ` Vincent Guittot
2014-04-15 7:53 ` Peter Zijlstra
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=535A8585.6030103@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=linux-arm-kernel@lists.infradead.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).