General sha1, memcopy, and string improvements

commit c5eec5e679d75a2d510e7fa18182f164835b480d
Author: Mandeep Singh Baines <msb@chromium.org>
Date:   Sat Dec 17 17:42:03 2011 -0800

    lib/sha1: use the git implementation of SHA-1

    For ChromiumOS, we use SHA-1 to verify the integrity of the root
    filesystem.  The speed of the kernel sha-1 implementation has a major
    impact on our boot performance.

    To improve boot performance, we investigated using the heavily optimized
    sha-1 implementation used in git.  With the git sha-1 implementation, we
    see a 11.7% improvement in boot time.

    10 reboots, remove slowest/fastest.

    Before:

      Mean: 6.58 seconds Stdev: 0.14

    After (with git sha-1, this patch):

      Mean: 5.89 seconds Stdev: 0.07

    The other cool thing about the git SHA-1 implementation is that it only
    needs 64 bytes of stack for the workspace while the original kernel
    implementation needed 320 bytes.

    Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
    Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
    Cc: Nicolas Pitre <nico@cam.org>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: linux-crypto@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 69fdf58c22e2195fccd3fa960bed0b47b75e3650
Author: Joachim Eastwood <manabian@gmail.com>
Date:   Sat Dec 17 17:43:27 2011 -0800

    Remove ARM sha1 routines

    Since commit 8827a4a6b397b07a341ba7fd36ffb91a7835207d
    ("lib/sha1: use the git implementation of SHA-1"), the ARM SHA1
    routines no longer work. The reason? They depended on the larger
    320-byte workspace, and now the sha1 workspace is just 16 words
    (64 bytes). So the assembly version would overwrite the stack randomly.

    The optimized asm version is also probably slower than the new improved
    C version, so there's no reason to keep it around.  At least that was
    the case in git, where what appears to be the same assembly language
    version was removed two years ago because the optimized C BLK_SHA1 code
    was faster.

    Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
    Cc: Andreas Schwab <schwab@linux-m68k.org>
    Cc: Nicolas Pitre <nico@fluxnic.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 1083cff373f09f06fbaf48a9034e152e90a18a37
Author: faux123 <reioux@gmail.com>
Date:   Mon Mar 19 17:22:43 2012 -0700

    Optimized ARM RWSEM algorithm

    RWSEM implementation for ARM using atomic functions.
    Heavily based on arch/sh/include/asm/rwsem.h

    Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>

commit 06bb376affc11d2b91d9dcb8a738f6c7eb378c64
Author: faux123 <reioux@gmail.com>
Date:   Mon Mar 19 17:14:04 2012 -0700

    lib/string: use glibc version

    the performance of memcpy and memmove of the general version is very
    inefficient, this patch improved them.

    Signed-off-by: Miao Xie <miaox*******>

commit efa5da91812e944a5d9373a1a0ba0df2dfbec7a2
Author: faux123 <reioux@gmail.com>
Date:   Mon Mar 19 17:11:57 2012 -0700

    lib/memcopy: use glibc version

    the kernel's memcpy and memmove is very inefficient. But the glibc version is
    quite fast, in some cases it is 10 times faster than the kernel version. So I
    introduce some memory copy macros and functions of the glibc to improve the
    kernel version's performance.

    The strategy of the memory functions is:
    1. Copy bytes until the destination pointer is aligned.
    2. Copy words in unrolled loops.  If the source and destination are not
       aligned in the same way, use word memory operations, but shift and merge
       two read words before writing.
    3. Copy the few remaining bytes.

    Signed-off-by: Miao Xie <miaox*******>

commit 19ecc0207893ff991219d6bd6cfba1684a6cc352
Author: Jeff Moyer <jmoyer@redhat.com>
Date:   Wed Jun 13 17:17:35 2012 -0700

    iosched: prevent aliased requests from starving other I/O

    Hi, Jens,

    If you recall, I posted an RFC patch for this back in July of last year:
    http://lkml.org/lkml/2010/7/13/279

    The basic problem is that a process can issue a never-ending stream of
    async direct I/Os to the same sector on a device, thus starving out
    other I/O in the system (due to the way the alias handling works in both
    cfq and deadline).  The solution I proposed back then was to start
    dispatching from the fifo after a certain number of aliases had been
    dispatched.  Vivek asked why we had to treat aliases differently at all,
    and I never had a good answer.  So, I put together a simple patch which
    allows aliases to be added to the rb tree (it adds them to the right,
    though that doesn't matter as the order isn't guaranteed anyway).  I
    think this is the preferred solution, as it doesn't break up time slices
    in CFQ or batches in deadline.  I've tested it, and it does solve the
    starvation issue.  Let me know what you think.

    Cheers,
    Jeff

    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>