linux-kernel - Re: [PATCH 16/24] Documentation: scheduler: correct spelling

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: <CAKfTPtC5gV3VF7S_BEJ9ndYnGwGuCRvYrKJTABSLHneYZVZvmQ@mail.gmail.com>
Date:   Thu, 9 Feb 2023 10:20:30 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Mukesh Ojha <quic_mojha@...cinc.com>
Subject: Re: [PATCH 16/24] Documentation: scheduler: correct spelling

On Thu, 9 Feb 2023 at 08:14, Randy Dunlap <rdunlap@...radead.org> wrote:
>
> Correct spelling problems for Documentation/scheduler/ as reported
> by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Juri Lelli <juri.lelli@...hat.com>
> Cc: Vincent Guittot <vincent.guittot@...aro.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: linux-doc@...r.kernel.org
> Reviewed-by: Mukesh Ojha <quic_mojha@...cinc.com>

Acked-by: Vincent Guittot <vincent.guittot@...aro.org>

> ---
>  Documentation/scheduler/sched-bwc.rst    |    2 +-
>  Documentation/scheduler/sched-energy.rst |    4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff -- a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst
> --- a/Documentation/scheduler/sched-bwc.rst
> +++ b/Documentation/scheduler/sched-bwc.rst
> @@ -186,7 +186,7 @@ average usage, albeit over a longer time
>  also limits the burst ability to no more than 1ms per cpu.  This provides
>  better more predictable user experience for highly threaded applications with
>  small quota limits on high core count machines. It also eliminates the
> -propensity to throttle these applications while simultanously using less than
> +propensity to throttle these applications while simultaneously using less than
>  quota amounts of cpu. Another way to say this, is that by allowing the unused
>  portion of a slice to remain valid across periods we have decreased the
>  possibility of wastefully expiring quota on cpu-local silos that don't need a
> diff -- a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst
> --- a/Documentation/scheduler/sched-energy.rst
> +++ b/Documentation/scheduler/sched-energy.rst
> @@ -82,7 +82,7 @@ through the arch_scale_cpu_capacity() ca
>  The rest of platform knowledge used by EAS is directly read from the Energy
>  Model (EM) framework. The EM of a platform is composed of a power cost table
>  per 'performance domain' in the system (see Documentation/power/energy-model.rst
> -for futher details about performance domains).
> +for further details about performance domains).
>
>  The scheduler manages references to the EM objects in the topology code when the
>  scheduling domains are built, or re-built. For each root domain (rd), the
> @@ -281,7 +281,7 @@ mechanism called 'over-utilization'.
>  From a general standpoint, the use-cases where EAS can help the most are those
>  involving a light/medium CPU utilization. Whenever long CPU-bound tasks are
>  being run, they will require all of the available CPU capacity, and there isn't
> -much that can be done by the scheduler to save energy without severly harming
> +much that can be done by the scheduler to save energy without severely harming
>  throughput. In order to avoid hurting performance with EAS, CPUs are flagged as
>  'over-utilized' as soon as they are used at more than 80% of their compute
>  capacity. As long as no CPUs are over-utilized in a root domain, load balancing