UPDATE: Tweak Enabled Slub Memory Allocator
UPDATE: Fix Insane speed & Add Working Kingdom Config with some debugging disabled
UPDATE: Add Vdd Interface, Update 1.8+ Voltages & Add 2.01ghz
UPDATE: Add Vdd Interface, Update 1.8+ Voltages & Add 2.01ghz
Revert "UPDATE: Add Vdd Interface, Update 1.8+ Voltages & Add 2.01ghz"

This reverts commit 26c30f39dc504a266ac95c03acba942697885272.
UPDATE: Opps Fix Up Voltages
UPDATE: Add Smartass, SmartassV2, Scary and LagFree
UPDATE: Kingdom_defconfig
UPDATE: Fix Htc Screw Up Causing All The Lag
ADD: Simple I/O Scheduler Thanks to Doomlord
lib: introduce some memory copy macros and functions

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@xxxxxxxxxxxxxx>

Conflicts:

	lib/Makefile
lib: improve the performance of memcpy and memmove of the general version

Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
lowmemorykiller: Don't try to kill the same pid over and over

  Under certain circumstances, a process can take awhile to
handle a sig-kill (especially if it's in a scheduler group with
a very low share ratio). When this occurs, lowmemkiller returns
to vmscan indicating the process memory has been freed - even
though the process is still waiting to die. Since the memory
hasn't actually freed, lowmemkiller is called again shortly after,
and picks the same process to die; regardless of the fact that
it has already been 'scheduled' to die and the memory has already
been reported to vmscan as having been freed.

  Solution is to check fatal_signal_pending() on the selected
task, and if it's already pending destruction return; indicating
to vmscan that no resources were freed on this pass.

Signed-off-by: San Mehat <san@google.com>
Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
UPDATE: Fix Sio For 3.0.x+ Since Not Included In elevator.h
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>
Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
Added optimized ARM RWSEM algorithm.

Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
Add dynamic writeback feature from 3.1

Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
Added optimized CRC32 algorithm.

Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
sched: don't call task_group() many times in set_task_rq()

It improves perfomance, especially if autogroup enabled.

The size of set_task_rq() was 0x180 and now it is 0xa0.

Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>
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>
Signed-off-by: 2fast4u88 <bk95ta391@gmail.com>