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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Aug 2018 13:50:31 +0100 From: Patrick Bellasi <patrick.bellasi@....com> To: Quentin Perret <quentin.perret@....com> Cc: peterz@...radead.org, rjw@...ysocki.net, linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, gregkh@...uxfoundation.org, mingo@...hat.com, dietmar.eggemann@....com, morten.rasmussen@....com, chris.redpath@....com, valentin.schneider@....com, vincent.guittot@...aro.org, thara.gopinath@...aro.org, viresh.kumar@...aro.org, tkjos@...gle.com, joel@...lfernandes.org, smuckle@...gle.com, adharmap@...eaurora.org, skannan@...eaurora.org, pkondeti@...eaurora.org, juri.lelli@...hat.com, edubezval@...il.com, srinivas.pandruvada@...ux.intel.com, currojerez@...eup.net, javi.merino@...nel.org Subject: Re: [PATCH v6 05/14] sched/topology: Reference the Energy Model of CPUs when available On 30-Aug 11:47, Quentin Perret wrote: > On Thursday 30 Aug 2018 at 11:00:20 (+0100), Patrick Bellasi wrote: > > Dunno... but, in any case, probably we don't care about using EAS until > > the boot complete, isn't it? > > So, as of now, EAS will typically start soon after CPUFreq. I don't see a > point in starting before, and I'm not sure if starting it later is > really what we want either ... It probably makes sense to start the > DVFS-related features (CPUFreq, EAS, ...) together. > > > Just to better understand, what is the most common activation path we expect ? > > > > 1. system boot > > 2. CPUs online > > 3. CPUFreq initialization > > 4. EM registered > > X. ??? > > X is sort of arch dependent (like the EM registration actually). For > arm/arm64, the arch topology driver (see drivers/base/arch_topology.c) > will rebuild the sched_domains once the capacities of CPU are > discovered. In previous versions, I had a patch that did that explicitly: > > https://lore.kernel.org/lkml/20180724122521.22109-14-quentin.perret@arm.com/ > > However, I dropped this patch for v6 because I rebased the series on top > of Morten's automatic flag detection patches, which happen to already do > that for me. More precisely, Morten's patches will rebuild the sched > domains if the SD_ASYM_CPUCAPACITY flag needs to be set somewhere in the > hierarchy. EAS depends on this flag anyway, so I guess it's fine to rely > on this rebuild to start EAS at the same time. > > I have been wondering for a while if such a 'loose' way of starting EAS > was alright or not. My conclusion was that it should be OK for now, > because that should suit all the users I can see in the short/medium > term. An alternative could be to introduce something like a notifier in > the EM framework in order to let other subsystems know that the EM is > complete or something along those lines. And then we could register a > callback on this notifier to rebuild the sched_domains. But that's added > complexity, which isn't really needed (yet). If that needs to be done to > accomodate the needs of new users/archs, we can still implement that > later :-) > > > N. partition_sched_domains > > build_perf_domains > > > > IOW, who do we expect to call build_perf_domains for the first time ? > > On arm/arm64, when the arch_topology driver calls rebuild_sched_domains. Great, I missed that point, which you actually call out in the cover letter. Thanks also for the more comprehensive explanation above! > Thanks ! > Quentin Cheers Patrick -- #include <best/regards.h> Patrick Bellasi
Powered by blists - more mailing lists