All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Josh Don <joshdon@google.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Clement Courbet <courbet@google.com>,
	Oleg Rombakh <olegrom@google.com>
Subject: Re: [PATCH] sched: Optimize __calc_delta.
Date: Wed, 3 Mar 2021 10:56:34 +0100	[thread overview]
Message-ID: <YD9dUkGhlRT8vvcy@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CABk29Ntt88BfqGz=Rjd5Mwyj+N0YLv0Z9QsZp8DgB-n+FV1Zgw@mail.gmail.com>

On Tue, Mar 02, 2021 at 12:57:37PM -0800, Josh Don wrote:
> From: Clement Courbet <courbet@google.com>
> 
> A significant portion of __calc_delta time is spent in the loop
> shifting a u64 by 32 bits. Use `fls` instead of iterating.
> 
> This is ~7x faster on benchmarks.
> 
> The generic `fls` implementation (`generic_fls`) is still ~4x faster
> than the loop.
> Architectures that have a better implementation will make use of it. For
> example, on X86 we get an additional factor 2 in speed without dedicated
> implementation.
> 
> On gcc, the asm versions of `fls` are about the same speed as the
> builtin. On clang, the versions that use fls (fls,fls64) are more than
> twice as slow as the builtin. This is because the way the `fls` function
> is written, clang puts the value in memory:
> https://godbolt.org/z/EfMbYe. This can be fixed in a separate patch.
> 
> ```
> name                                   cpu/op
> BM_Calc<__calc_delta_loop>             9.57ms ±12%
> BM_Calc<__calc_delta_generic_fls>      2.36ms ±13%
> BM_Calc<__calc_delta_asm_fls>          2.45ms ±13%
> BM_Calc<__calc_delta_asm_fls_nomem>    1.66ms ±12%
> BM_Calc<__calc_delta_asm_fls64>        2.46ms ±13%
> BM_Calc<__calc_delta_asm_fls64_nomem>  1.34ms ±15%
> BM_Calc<__calc_delta_builtin>          1.32ms ±11%
> ```
> 
> Signed-off-by: Clement Courbet <courbet@google.com>
> Signed-off-by: Josh Don <joshdon@google.com>
> ---
>  kernel/sched/fair.c  | 30 ++++++++++++++++++++++--------
>  kernel/sched/sched.h |  1 +
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8a8bd7b13634..67e5a1d536ad 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -214,6 +214,16 @@ static void __update_inv_weight(struct load_weight *lw)
>   lw->inv_weight = WMULT_CONST / w;
>  }
> 
> +/*
> + * An fls that handles an u32 value on architectures
> + * where `sizeof(unsigned int) < 32`.
> + */
> +#if (__SIZEOF_INT__ >= 32)

This should never happen, we use ILP32 or LP64 for Linux.

> +# define FLS_AT_LEAST_32(v) fls(v)
> +#else
> +# define FLS_AT_LEAST_32(v) fls64(v)
> +#endif
> +
>  /*
>   * delta_exec * weight / lw.weight
>   *   OR
> @@ -229,27 +239,31 @@ static void __update_inv_weight(struct load_weight *lw)
>  static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct
> load_weight *lw)
>  {
>   u64 fact = scale_load_down(weight);
> + u32 fact_hi = (u32)(fact >> 32);
>   int shift = WMULT_SHIFT;
> + int fs;
> 
>   __update_inv_weight(lw);
> 
> - if (unlikely(fact >> 32)) {
> - while (fact >> 32) {
> - fact >>= 1;
> - shift--;
> - }
> + if (unlikely(fact_hi)) {
> + fs = FLS_AT_LEAST_32(fact_hi);

you made fact_hi u32, why can't we unconditionally use fls() ?

> + shift -= fs;
> + fact >>= fs;
>   }
> 
>   fact = mul_u32_u32(fact, lw->inv_weight);
> 
> - while (fact >> 32) {
> - fact >>= 1;
> - shift--;
> + fact_hi = (u32)(fact >> 32);
> + if (fact_hi) {
> + fs = FLS_AT_LEAST_32(fact_hi);
> + shift -= fs;
> + fact >>= fs;
>   }
> 
>   return mul_u64_u32_shr(delta_exec, fact, shift);
>  }

Horrific whitespace damage..

  reply	other threads:[~2021-03-03 15:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 19:52 [PATCH] sched: Optimize __calc_delta Josh Don
2021-02-26 21:03 ` Peter Zijlstra
2021-03-02 20:55   ` Josh Don
2021-03-02 20:57     ` Josh Don
2021-03-03  9:56       ` Peter Zijlstra [this message]
2021-03-03 21:59         ` Josh Don
2021-03-03 22:46         ` [PATCH v2] " Josh Don
2021-03-04  8:31           ` Peter Zijlstra
2021-03-04 17:34           ` Nick Desaulniers
2021-03-04 18:24             ` Sedat Dilek
2021-03-04 19:21               ` Sedat Dilek
2021-03-05  1:04             ` Josh Don
2021-03-05 17:13             ` David Laight
2021-03-10 11:26           ` [tip: sched/core] sched: Optimize __calc_delta() tip-bot2 for Clement Courbet
2021-03-03 10:02       ` [PATCH] sched: Optimize __calc_delta Peter Zijlstra
2021-03-03 22:00         ` Josh Don
2021-03-03  9:49     ` Peter Zijlstra
2021-02-28 15:15 ` [sched] 4112549ee5: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_fwd_prog_nr[rcutorture] kernel test robot
2021-02-28 15:15   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YD9dUkGhlRT8vvcy@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=courbet@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=olegrom@google.com \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.