On Wed, May 13, 2020 at 5:03 PM Valentin Schneider <valentin.schneider@xxxxxxx> wrote: > > > On 13/05/20 14:43, john mathew wrote: > > +========================= > > +Capacity-Aware Scheduling > > +========================= > > + > > Thanks for taking a jab at this. At a glance it looks okay, with one > comment below. > > FWIW I still intend to write a more pamphlet-sized thing, I'll toss > something out in the coming weeks - depending on where this goes, I might > base it on this. > > > +Scheduling load balancing on Asymmetric Multiprocessor systems was improved > > +through the introduction of Capacity-Aware Scheduling. It identifies the > > +most efficient CPU to assign a task based on its capacity. This capacity > > +may be asymmetric due to heterogeneous computing architecture such > > +as ARM big.LITTLE. Scheduler gets information about asymmetric capacities > > +when the scheduler domain hierarchy is built using build_sched_domains(). > > +CPU capacities are provided to the scheduler topology code through the > > +architecture specific implementation of the arch_scale_cpu_capacity(). > > +The SD_ASYM_CPUCAPACITY flag is set by the scheduler topology for a domain > > +in the hierarchy where all CPU capacities are visible for any cpu's point > > +of view on asymmetric CPU capacity systems. The scheduler can then take > > +capacity asymmetry into account when load balancing. > > + > > +Initial CPU capacities are derived from the Device Tree and CPU frequency. > > +For RISC-V & ARM64 it is done in drivers/base/arch_topology.c. A cpu-map > > +device tree is parsed to obtain the cpu topology and the initial CPU capacity > > +is set using the CPUFreq subsystem. A callback is registered to the CPUFreq > > +subsystem to rebuild sched_domains when CPU frequency changes. > > + > > We don't rebuild domains on frequency changes (that would be ludicrous!), > rather we do that on policy changes. It's mostly because we need to wait > for cpufreq to be loaded before having a complete view over the capacities > of the CPUs (which is a mix of µarch and frequencies), i.e. we need to > rebuild the SD's again once cpufreq comes up. Fixed in v5 of the patchset. Thanks
