Re: [PATCH] fix do_xor_speed 64-bit devision issue on 32-bits arch

[Benny Halevy <bhalevy@tonian.com>]

On 2011-12-23 15:25, Jim Rees wrote:
> fanchaoting wrote:
> 
>   Benny Halevy 写道:
>   > I am trying to build a pnfs client on a 32 bit system  and the
>   > pnfs-latest  kernel fails to compile. I get the following error
>   > 
>   >  >  Building modules, stage 2.
>   >  >  TEST    posttest
>   >  > MODPOST 2046 modules
>   >  >ERROR: "__udivdi3" [crypto/xor.ko] undefined!
>   >  >make[1]: *** [__modpost] Error 1
>   >  >make: *** [modules] Error 2
>   >  >make: *** Waiting for unfinished jobs....
>   >  >Succeed: decoded and checked 1244492 instructions
>   > 
>   > Reported-by: Rita Sequeira <rita.prajval@gmail.com>
>   > Signed-off-by: Benny Halevy <bhalevy@tonian.com>
>   > ---
>   > 
>   > untested patch yet...
>   > 
>   >  crypto/xor.c |    3 ++-
>   >  1 files changed, 2 insertions(+), 1 deletions(-)
>   > 
>   > diff --git a/crypto/xor.c b/crypto/xor.c
>   > index 65433f5..2151ded 100644
>   > --- a/crypto/xor.c
>   > +++ b/crypto/xor.c
>   > @@ -95,7 +95,8 @@
>   >  
>   >  	ns_end -= ns_begin;
>   >  	if (ns_end > 0)
>   > -		speed = BENCH_SIZE / 1024 * count * NSEC_PER_SEC / ns_end;
>   > +		speed = BENCH_SIZE / 1024 * count *
>   > +				(unsigned)(NSEC_PER_SEC / ns_end);
>   >  	else
>   >  		speed = 17;
>   >  	tmpl->speed = speed;
>   
>   Hi,I also meet this problem ,but when  i use you patch ,i can't solve this
>   problem.
> 
> Maybe something like this?
> 
> speed = do_div(BENCH_SIZE, 1024) * count * do_div(NSEC_PER_SEC, ns_end);
> 
> This might not be exactly right because it changes the operator precedence,
> but it should eliminate the calls to __udivdi3.

Hmm, you mean execution order? (which you do not)
C (and fortunately gcc too :) treats multiplication and division with the
same priority and executes them from left to right...

Boaz, please ack...

Benny

> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html