Re: Arch maintainers Ahoy!

[David Miller <davem@davemloft.net>]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 23 May 2012 11:27:00 -0700

> It's not faster to just do something like
> 
>    int byte = 4;
> 
> #if CONFIG_64BIT
>    byte = 8;
>    if (has_zero_32bit(value >> 32)) {
>        value >>= 32;
>        byte = 4;
>    }
> #endif
>    if (has_zero_16(value >> 16)) {
>       value >>= 16;
>       byte -= 2;
>    }
>    if (!value & 0xff00)
>       byte--;
>    return byte;
> 
> which looks like it might generate ok code?

It might be, I'll play around with it.

FWIW, when I code this end case in assembler on sparc64 I just go for
a bunch of conditional moves, so I'll try to come up with something
similar to the above that gcc will emit reasonably.

> Btw, when benchmarking, make sure that your branches do not predict
> well. Because in real life they won't predict well. So you can't
> benchmark the mask->byte function with some  well-behaved input that
> commonly returns the same value.

Indeed, and that's why I'd prefer it if gcc were to emit conditional
moves :-)

>> For reference here is the final version of the sparc commit, it works
>> and I've been running tests on it since last night.  I'm extrmely
>> confident the C code will work on any big-endian machine.
> 
> Umm. Except your "top of address space" thing is entirely sparc-specific.

Although a bit more expensive than what you can do on the x86 side
with these tests, I think my code should work.

Comparing get_fs() with USER_DS should be portable enough, as should
STACK_TOP, right?  Or does STACK_TOP have some weird semantics on some
architectures that I'm not aware of?

The only other thing is how we are using ~0UL as the limit for the
kernel, and for all practical purposes that ought to be fine too.