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: <20160524131610.GG27946@e105550-lin.cambridge.arm.com> Date: Tue, 24 May 2016 14:16:10 +0100 From: Morten Rasmussen <morten.rasmussen@....com> To: Vincent Guittot <vincent.guittot@...aro.org> 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 Tue, May 24, 2016 at 02:12:38PM +0200, Vincent Guittot wrote: > 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? Yes. select_idle_sibling() is only used to choose among equal capacity cpus (capacity_orig). > 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 The test in patch 9 is to determine whether we are happy with the capacity of the previous cpu, or we should go look for one with more capacity. I don't see how we can use select_idle_sibling() unmodified for sched domains containing cpus of different capacity to select an appropriate cpu. It is just picking an idle cpu, it might have high capacity or low, it wouldn't care. How would you avoid the overhead of checking capacity and utilization of the cpus and still pick an appropriate cpu?
Powered by blists - more mailing lists