RE: [PATCH] perf/x86/amd/power: Use div64_u64 onstead of do_div()

[David Laight <David.Laight@ACULAB.COM>]

From: Linus Torvalds
> Sent: 06 May 2024 17:46
> 
> On Mon, 6 May 2024 at 09:40, David Laight <David.Laight@aculab.com> wrote:
> > >
> > > We don 't do stupid things in the kernel. We basically never need the
> > > 64-by-64 divide.
> >
> > There are 381 references to div64_u64() some of them are just plain stupid.
> > Constant divisors of 100 and 1000 and div64_u64(x_ns * 100, y_us * 1000).
> 
> Sadly, some peopel will get the compile error for "you can't do that"
> because they did a regular "a = b / c" and gcc created a mess, and
> then they mindlessly just replace it with div64_u64".

A bit like the mindless min_t() - not hard to find:
	len = min_t(unsigned int, len, sizeof (int));
	if (len < 0)
		return -ERANGE;

> > But someone wrote a script that complains that is a full 64bit divide
> > on 64bit systems - so suggests div64_u64().
> 
> Yeah, that's well-intentioned, but it screws up.

The suggestion should be to double check the domain of the divisor,
and then change the type to u32.

> The reason is that "do_div()" _always_ does a 64-by-32 divide, and
> then if you have a divisor that is "long" (which is indeed 32 bit on
> 32-bit architectures), now on 64-bit architectures it truncates what
> can be a 64-bit value.
> 
> So we probably _should_ have made "do_div()" be a "64-by-long" divide.

Or got through the kernel and change lots of the 'long' to 'u32' :-)
I'm sure a lot are there because people were scared int might be 16bit.
Perhaps M$ got it right by leaving 'long' as 32bit :-)
But really what was the last 16bit Unix?
I never used ICL's 286 unix port - that might have been 16bit.
All the 386 ones were 32bit, as was the VAX (never used one).
So we're looking at 1970's systems like the AT&T 3B2 and DEC pdp-11.
Certainly far before you'd even though of Linux.

> On actual 64-bit architectures, doing a 64-bti divide is typically
> fine (I can imagine some broken cases, but not enough to care).

Well Intel x86 always take twice as long for the full 128 by 64 divide
than the 64 by 32 one (amd is the same speed if the values fit).
So selecting between the two divides may make sense.
OTOH you probably don't want to speculatively execute the wrong divide! 

> The whole problem is because of 32-bit architectures.

Indeed.
Both x86 and m68k have a 64 by 32 divide. I'm not whether any other do.
Nios-II wont (it may not even have divide), probably all MIPS derivatives
are the same (including RISC-V).
The suggested divide function in my sparc-32 book is several pages long.
(Quite what does the to I-cache is any-bodies guess.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)