Re: [PATCH] Kill div64.h dupes, parenthesize do_div() macro params

From: Bernardo Innocenti (
Date: Tue Jul 01 2003 - 23:37:24 EST

On Wednesday 02 July 2003 05:36, Peter Chubb wrote:

> Bernardo> If there are architectures where gcc doesn't implement
> Bernardo> divisions correctly, this issue should be solved in gcc, not
> Bernardo> by adding a silly macro to the kernel.
> The issue is that on 32-bit platforms, 64bit divided by 32 bit is
> handed off to a subroutine _udivdi3 which isn't linked into the
> kernel, and which in any case does a full 64 bit by 64-bit division
> (which is slow).

 I see. It's ashaming that the gcc people didn't care special casing
the quite common 64/32 case in the x86 machine description or at least
in libgcc.

> Using do_div() allows one to generate near-optimal code for a 64by32
> bit division/remainder on platforms (e.g., IA32) which have problems,
> and generating something sane for other platforms (e.g., IA64).

 I agree. I'd prefer to see it fixed in gcc, but until then...

> Platforms that never expect to deal with a 64-bit number just redefine
> the macro in terms of long. Which means that printing out long longs
> doesn't work properly on those architectures.

 A function which changes its semantics depending on the platform is
definitely a ugly hack.

 A cleaner way to address this problem would be using platform-specific
typedefs to reduce the size of specific objects to 32bits on smaller systems.

 In mm/vmscan.c:shrink_slab() you'll find this:

       long long delta;

       delta = scanned * shrinker->seeks;
       delta *= (*shrinker->shrinker)(0, gfp_mask);
       do_div(delta, pages + 1);
       shrinker->nr += delta;

 This is _BAD_ because delta will be 128bits on some 64bit systems
and 64bit, but truncated to 32bit in do_div(), on some other systems.

 Using at least uint64_t would solve the first problem, but anyone
looking at this code wouldn't realize the result could get truncated
by some do_div() implementations.

 What can we do about that? This time I don't have a clean solution to

  // Bernardo Innocenti - Develer S.r.l., R&D dept.

Please don't send Word attachments -

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:15 EST