On Thursday May 11, [email protected] wrote:
>
> We end up with
>
> static inline u32 hash_u32(u32 val, unsigned int bits)
> {
> u32 hash = val;
>
> /* On some cpus multiply is faster, on others gcc will do shifts */
> hash *= GOLDEN_RATIO_PRIME_32;
>
> /* High bits are more random, so use them. */
> return hash >> (32 - bits);
> }
>
> static inline u32 hash_u64(u64 val, unsigned int bits)
> {
> u32 hi = val >> 32;
> return hash_u32(hash_u32(val, 32) ^ hi, bits);
> }
>
> So if one does
>
> hash_u64(foo, 44)
>
> we have a negative shift distance.
True. But as hash_u64 returns a u32, asking for 44 bits would be
clearly unwise. It really no different than doing
hash_long(foo, 100)
Based on the return type, that is equally unwise.
Fortunately no one (current) askes for more than 14 bits.
Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
