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: <20160524133642.GH27946@e105550-lin.cambridge.arm.com> Date: Tue, 24 May 2016 14:36:43 +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 03:27:05PM +0200, Vincent Guittot wrote: > On 24 May 2016 at 15:16, Morten Rasmussen <morten.rasmussen@....com> wrote: > > 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? > > My point is that there is some wake up case where we don't care about > the capacity and utilization of cpus even for cross capacity migration > and we will never take benefit of this fast path. > You have added an extra check for setting want_affine in patch 9 which > uses capacity and utilization of cpu to disable this fast path when a > task needs more capacity than available. Can't you use this function > to disable the want_affine for cross-capacity migration situation that > cares of the capacity and need the full scan of sched_domain but keep > it enable for other cases ? It is not clear to me what the other cases are. What kind of cases do you have in mind?
Powered by blists - more mailing lists