Makefile update
Remove explicit inlining to fix Linaro build
[PATCH] ARM: makefile: work around toolchain bug in recent versions of binutils

Recent upstream versions of binutils fail to assembler compressed/head.S
when passed the -march=all option:

http://lists.gnu.org/archive/html/bug-binutils/2011-04/msg00162.html

The recommended workaround from the tools folks is not to pass the
option, and instead let the assembler deduce the CPU type based on the
features used by the code.

Signed-off-by: Will Deacon <will.deacon@arm.com>

Conflicts:
	arch/arm/boot/compressed/Makefile
Makefile edits
Workaround for outdated kernel tree

Conflicts:
	drivers/misc/tzic.c
block: add row iosched

Change-Id: I01857784f0506a0b443dd01c801908e0beea5f66
Enable ROW and set to default
fs/dyn_sync_cntrl: dynamic sync control The dynamic sync
 control interface uses Android kernel's unique early
 suspend / lat resume interface.

While screen is on, file sync is disabled
when screen is off, a file sync is called to flush all outstanding writes
and restore file sync operation as normal.

Signed-off-by: Paul Reioux <reioux@gmail.com>
Set Dynamic Fsync:Added missing driver to git

Conflicts:
	arch/arm/configs/vigor_defconfig

Conflicts:
	arch/arm/configs/cyanogenmod_t0ltecdma_defconfig
Enable Dynamic Fsync
netfilter: xt_log.h: fix warning: value computed is not used
Added optimized CRC32 algorithm.

Conflicts:
	arch/arm/configs/vigor_aosp_defconfig
Enable optimized CRC32
lowmemorykiller: Compact memory when killing processes

* Memory compaction is never invoked on Android because we avoid swap
   and don't allocate huge pages. Fix it by invoking compaction from the LMK when
   a process is killed to reduce memory fragmentation.

Change-Id: I2bda790c2093e65fd6f43d52ea5149d6b57cb1e9

Conflicts:
	drivers/staging/android/lowmemorykiller.c

Conflicts:
	drivers/staging/android/lowmemorykiller.c
	mm/compaction.c
lowmemorykiller: Use asynchronous compaction

Change-Id: I6a65d06fc30b88fcedaaf1abf1855fdd19e3c912

Conflicts:
	mm/compaction.c

Conflicts:
	mm/compaction.c
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*******>

Conflicts:
	lib/Makefile
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*******>
[patch] iosched: prevent aliased requests from starving other I/O

http://lkml.indiana.edu/hypermail/linux/kernel/1106.0/00548.html

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
Optimized Async I/O
Lower VFS cache pressure

VFS cache pressure defines how readily the kernel will drop caches to recovery memory.
We lower it here to allow more RAM to be used for caches, which should increase
performance of frequently used apps.  The kernel will still drop the caches when we
need the memory.  We don't make it too low, because otherwise, performance could
suffer due to insufficient free memory.