lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAKfTPtCXyMQpDYQt+jCwmRdq8BoQ-n3S+xFo-YOwxmWed6x6ig@mail.gmail.com> Date: Tue, 24 May 2016 14:12:38 +0200 From: Vincent Guittot <vincent.guittot@...aro.org> To: Morten Rasmussen <morten.rasmussen@....com> Cc: Peter Zijlstra <peterz@...radead.org>, "mingo@...hat.com" <mingo@...hat.com>, Dietmar Eggemann <dietmar.eggemann@....com>, Yuyang Du <yuyang.du@...el.com>, mgalbraith@...e.de, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations On 24 May 2016 at 12:29, Morten Rasmussen <morten.rasmussen@....com> wrote: > On Tue, May 24, 2016 at 11:10:28AM +0200, Vincent Guittot wrote: >> On 23 May 2016 at 12:58, Morten Rasmussen <morten.rasmussen@....com> wrote: >> > If the system has cpu of different compute capacities (e.g. big.LITTLE) >> > let affine wakeups be constrained to cpus of the same type. >> >> Can you explain why you don't want wake affine with cpus with >> different compute capacity ? > > I should have made the overall idea a bit more clear. The idea is to > deal with cross-capacity migrations in the find_idlest_{group, cpu}{} > path so we don't have to touch select_idle_sibling(). > select_idle_sibling() is critical for wake-up latency, and I'm assumed > that people wouldn't like adding extra overhead in there to deal with > capacity and utilization. So this means that we will never use the quick path of select_idle_sibling for cross capacity migration but always the one with extra overhead? Patch 9 adds more tests for enabling wake_affine path. Can't it also be used for cross capacity migration ? so we can use wake_affine if the task or the cpus (even with different capacity) doesn't need this extra overhead > > So the overall idea is that symmetric capacity systems, everything > should work as normal. For asymmetric capacity systems, we restrict > select_idle_sibling() to only look among same-capacity cpus and then use > wake_cap() to use find_idlest_{group, cpu}() to look wider if we think > should look for cpu with higher capacity than the previous one. So, for > assymmetric cpus we take one of the two routes depending on whether a > cpu of the same capacity as the previous one is okay. > > Do that make any sense? > >> >> > >> > cc: Ingo Molnar <mingo@...hat.com> >> > cc: Peter Zijlstra <peterz@...radead.org> >> > >> > Signed-off-by: Morten Rasmussen <morten.rasmussen@....com> >> > --- >> > kernel/sched/core.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> > index d9619a3..558ec4a 100644 >> > --- a/kernel/sched/core.c >> > +++ b/kernel/sched/core.c >> > @@ -6410,6 +6410,9 @@ sd_init(struct sched_domain_topology_level *tl, int cpu) >> > sd->idle_idx = 1; >> > } >> > >> > + if (sd->flags & SD_ASYM_CPUCAPACITY) >> > + sd->flags &= ~SD_WAKE_AFFINE; >> > + >> > sd->private = &tl->data; >> > >> > return sd; >> > -- >> > 1.9.1 >> >
Powered by blists - more mailing lists