linux-kernel - Re: [PATCH v2] sched/cputime: make scale

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHk-=wjjxDY6XzKKPEE1S+AUXycmo8XNpX2C-jO4fS+qU8ObpA@mail.gmail.com>
Date:   Tue, 19 May 2020 11:33:34 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Fox <afox@...hat.com>,
        Stephen Johnston <sjohnsto@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stanislaw Gruszka <sgruszka@...hat.com>
Subject: Re: [PATCH v2] sched/cputime: make scale_stime() more precise

On Tue, May 19, 2020 at 10:25 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> --- a/include/linux/math64.h
> +++ b/include/linux/math64.h
> @@ -263,6 +263,47 @@ static inline u64 mul_u64_u32_div(u64 a, u32 mul, u32 divisor)
>  }
>  #endif /* mul_u64_u32_div */
>
> +#ifndef mul_u64_u64_div_u64
> +static inline u64 mul_u64_u64_div_u64(u64 a, u64 b, u64 c)

Do we really want to inline this? Particularly if we expect this to be
the "architecture doesn't have a better version" case?

It's not like we'd expect people to call it with constant values that
could be optimized by inlining, do we? If any of the values are
actually constants and it's performance-critical, the code is likely
better off using some special helper rather than this anyway.

So I'd much rather see it as a weak function defined in
lib/math/div64.c, and then architectures don't even need to override
it at all. Just let them define their own (inline or not) function,
and we have this as a weak fallback.

No?

               Linus