Optimize ext2_find_next_zero_bit. Gives about 25% perf improvement with a
rsync test with ext3.
Signed-off-by: NRandolph Chung <tausq@parisc-linux.org>

fix ext3 performance - ext2_find_next_zero() was culprit.
Kudos to jejb for pointing out the the possibility that ext2_test_bit
and ext2_find_next_zero() may in fact not be enumerating bits in
the bitmap because of endianess. Took sparc64 implementation and
adapted it to our tree. I suspect the real problem is ffz() wants
an unsigned long and was getting garbage in the top half of the
unsigned int. Not confirmed but that's what I suspect.
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>

Fix find_next_bit for 32-bit
Make masking consistent for bitops

From: Joel Soete <soete.joel@tiscali.be>
Signed-off-by: NRandolph Chung <tausq@parisc-linux.org>

Add back incorrectly removed ext2_find_first_zero_bit definition
Signed-off-by: NJames Bottomley <jejb@parisc-linux.org>

Fixup bitops.h to use volatile for *_bit() ops

Based on this email thread:
       http://marc.theaimsgroup.com/?t=108826637900003

In a nutshell:
        *_bit() want use of volatile.
        __*_bit() are "relaxed" and don't use spinlock or volatile.

other minor changes:
o replaces hweight64() macro with alias to generic_hweight64() (Joel Soete)
o cleanup ext2* macros so (a) it's obvious what the XOR magic is about
  and (b) one version that works for both 32/64-bit.
o replace 2 uses of CONFIG_64BIT with __LP64__. bitops.h used both.
  I think header files that might go to user space should use
  something userspace will know about (__LP64__).
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>

Move SHIFT_PER_LONG to standard location for BITS_PER_LONG (asm/types.h)
and ditch the second definition of BITS_PER_LONG in bitops.h
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>