linux-kernel - Re: [RFC PATCH v4 2/3] docs: scheduler: Add scheduler overview documentation

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <jhjy2pwq6e2.mognet@arm.com>
Date:   Wed, 13 May 2020 15:03:17 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     john mathew <john.mathew@...kie.com>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        corbet@....net, mingo@...hat.com, peterz@...radead.org,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, tsbogend@...ha.franken.de,
        lukas.bulwahn@...il.com, x86@...nel.org,
        linux-mips@...r.kernel.org, tglx@...utronix.de,
        mostafa.chamanara@...il.com, willy@...radead.org,
        Mostafa Chamanara <mostafa.chamanara@...emark.com>,
        Oleg Tsymbal <oleg.tsymbal@...kie.com>
Subject: Re: [RFC PATCH v4 2/3] docs: scheduler: Add scheduler overview documentation


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.