Messages in this thread | | | Date | Mon, 22 Jul 2019 21:45:24 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] sched/cputime: make scale_stime() more precise |
| |
On Fri, Jul 19, 2019 at 04:03:25PM +0200, Oleg Nesterov wrote: > On 07/19, Peter Zijlstra wrote: > > Included below is also an x86_64 implementation in 2 instructions. > > But we need the arch-neutral implementation anyway, the code above > is the best I could invent.
Agreed; we do. Depending on the cost of division and if the arch has a 64x64->128 mult, it might be better to compute a reciprocal and multiply that, but yes, long staring didn't get me much better ideas either.
> But see below! > > > I'm still trying see if there's anything saner we can do... > > Oh, please, it is not that I like my solution very much, I would like > to see something more clever. > > > static noinline u64 mul_u64_u64_div_u64(u64 a, u64 b, u64 c) > > { > > u64 q; > > asm ("mulq %2; divq %3" : "=a" (q) : "a" (a), "rm" (b), "rm" (c) : "rdx"); > > return q; > > } > > Heh. I have to admit that I didn't know that divq divides 128bit by > 64bit. gcc calls the __udivti3 intrinsic in this case so I wrongly > came to conclusion this is not simple even on x86_64. Plus the fact > that linux/math64.h only has mul_u64_u64_shr()...
C wants to promote the dividend and divisor to the same type (int128) and then it runs into trouble.
But yeah, I don't know how many other 64bit archs can pull off that trick. I asked, and ARGH64 cannot do that 128/64 (although it can do a 64x64->128 in two instructions).
| |