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

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

[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;
-- 
1.7.6

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

[fanchaoting]

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.

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

[Jim Rees]

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.

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

[Benny Halevy]

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

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

[Jim Rees]

Benny Halevy wrote:

  > 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...

Yes, execution order.  The original code executes left-to-right, my code
executes the divisions first.

But I wouldn't blindly apply this without understanding what's going on
here.  I thought the -fno-tree-scev-cprop compiler flag was supposed to
emit division code instead of calling into a library.

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

[Boaz Harrosh]

On 12/25/2011 07:31 AM, Benny Halevy wrote:
> 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...
> 

Hi

Please trash this patch for now. I will carry it out of tree for my use.
(Looks I'm the only one who's using UML and the XOR engine)

By next Connectathon I'll have a better patch sent to the right
people.

Thanks for your efforts, and sorry for the grief it caused.
Boaz

> 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

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

[Jim Rees]

Boaz Harrosh wrote:

  Please trash this patch for now. I will carry it out of tree for my use.
  (Looks I'm the only one who's using UML and the XOR engine)

UML would explain it.  Regular kernels should be ok.

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

[Benny Halevy]

No problem.  I'll revert it then.

Thanks,

Benny

On Sun, Dec 25, 2011 at 5:25 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 12/25/2011 07:31 AM, Benny Halevy wrote:
>> 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...
>>
>
> Hi
>
> Please trash this patch for now. I will carry it out of tree for my use.
> (Looks I'm the only one who's using UML and the XOR engine)
>
> By next Connectathon I'll have a better patch sent to the right
> people.
>
> Thanks for your efforts, and sorry for the grief it caused.
> Boaz
>
>> 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
>