linux-kernel - Re: [PATCH 3/3] sched/fair: Fix ascii art by relpacing tabs

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: <CAKfTPtAi9XTyLGrCqU9A-SMoPVqd45N1Tcytqj1E6SMjb4ffxA@mail.gmail.com>
Date:   Thu, 27 May 2021 15:27:01 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Odin Ugedal <odin@...d.al>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] sched/fair: Fix ascii art by relpacing tabs

On Tue, 18 May 2021 at 14:55, Odin Ugedal <odin@...d.al> wrote:
>
> When using something other than 8 spaces per tab, this ascii art
> makes not sense, and the reader might end up wondering what this
> advanced equation "is".

Documentation/process/coding-style.rst says to use 8 characters for
tab so we should not really consider other tab value

That being said the numerators and other parts of the equation use
spaces whereas denominators use tabs. so using space everywhere looks
good for me

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

>
> Signed-off-by: Odin Ugedal <odin@...d.al>
> ---
>  kernel/sched/fair.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e7423d658389..c872e38ec32b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3142,7 +3142,7 @@ void reweight_task(struct task_struct *p, int prio)
>   *
>   *                     tg->weight * grq->load.weight
>   *   ge->load.weight = -----------------------------               (1)
> - *                       \Sum grq->load.weight
> + *                       \Sum grq->load.weight
>   *
>   * Now, because computing that sum is prohibitively expensive to compute (been
>   * there, done that) we approximate it with this average stuff. The average
> @@ -3156,7 +3156,7 @@ void reweight_task(struct task_struct *p, int prio)
>   *
>   *                     tg->weight * grq->avg.load_avg
>   *   ge->load.weight = ------------------------------              (3)
> - *                             tg->load_avg
> + *                             tg->load_avg
>   *
>   * Where: tg->load_avg ~= \Sum grq->avg.load_avg
>   *
> @@ -3172,7 +3172,7 @@ void reweight_task(struct task_struct *p, int prio)
>   *
>   *                     tg->weight * grq->load.weight
>   *   ge->load.weight = ----------------------------- = tg->weight   (4)
> - *                         grp->load.weight
> + *                         grp->load.weight
>   *
>   * That is, the sum collapses because all other CPUs are idle; the UP scenario.
>   *
> @@ -3191,7 +3191,7 @@ void reweight_task(struct task_struct *p, int prio)
>   *
>   *                     tg->weight * grq->load.weight
>   *   ge->load.weight = -----------------------------              (6)
> - *                             tg_load_avg'
> + *                             tg_load_avg'
>   *
>   * Where:
>   *
> --
> 2.31.1
>