Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 19 May 2020 11:33:34 -0700 | Subject | Re: [PATCH v2] sched/cputime: make scale_stime() more precise |
| |
On Tue, May 19, 2020 at 10:25 AM Peter Zijlstra <peterz@infradead.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
| |