fs: improve generic fsync

Conflicts:

	fs/libfs.c
android: logger: free some more ram
mmc: decrease wakelock timeout
suspend: shorten time to enter sleep state

Conflicts:

	kernel/power/process.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>

Conflicts:

	kernel/power/process.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

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*******>

Conflicts:

	lib/string.c

Conflicts:

	lib/string.c
ARM: fault: assume no context when IRQs are disabled during data abort.

Bail out early if IRQs are disabled in do_page_fault or else
  [14415.157266] BUG: sleeping function called from invalid context at arch/arm/mm/fault.c:301

Russell King's idea from
  http://comments.gmane.org/gmane.linux.ports.arm.omap/59256

Signed-off-by: JP Abgrall <jpa@google.com>
ARM: Avoid extra calls to the C compiler

Starting up the C compiler can be a slow operation on some systems.
Though these calls don't individually take a lot of time, they add up.
Rearrange the ARM Makefile a bit to avoid extra calls to the compiler
when they can be easily avoided.

When running with the Chrome OS ARM cross compiler
"armv7a-cros-linux-gnueabi-", this shaved .55 seconds (from 5.31
seconds to 4.76 seconds) off an incremental build of the kernel:
  time make -j32 ARCH=arm CROSS_COMPILE=armv7a-cros-linux-gnueabi-

Thanks to Mike Frysinger for the clean trick to make this work.

BUG=chromium:253588
TEST=Build incremental (no-op) build in ChromeOS before and after.
With this change alone we save 4.25 seconds (from 44.141 seconds to
39.891 seconds).
TEST=Build and boot; run trybots.

This patch has been posted upstream:
  https://patchwork.kernel.org/patch/2777841/

Change-Id: I79b32012abd3018578f01cc5841d1e7b1e962463
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59879

Conflicts:

	arch/arm/Makefile

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
nohz: Reduce overhead under high-freq idling patterns

One testbox of mine (Intel Nehalem, 16-way) uses MWAIT for its idle routine,
which apparently can break out of its idle loop rather frequently, with
high frequency.

In that case NO_HZ_FULL=y kernels show high ksoftirqd overhead and constant
context switching, because tick_nohz_stop_sched_tick() will, if
delta_jiffies == 0, mis-identify this as a timer event - activating the
TIMER_SOFTIRQ, which wakes up ksoftirqd.

Fix this by treating delta_jiffies == 0 the same way we treat other short
wakeups, delta_jiffies == 1.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Geoff Levand <geoff@infradead.org>
Cc: Gilad Ben Yossef <gilad@benyossef.com>
Cc: Hakan Akkan <hakanakkan@gmail.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire. From http://ripke.com/loadavg/moire.
mm: decrease default dirty ratio

The default dirty ratio is chosen to be a compromise between throughput and
overall system latency. On a desktop, if an application writes to disk a lot,
that application should be the one to slow down rather than the desktop as a
whole. At higher dirty ratio settings, an application could write a lot to
disk and then happily use lots of CPU time after that while the rest of the
system is busy waiting on that naughty application's disk writes to complete
before anything else happening.

Lower ratios mean that the application that do a lot of disk writes end up
being responsible for their own actions and they're the ones that slow down
rather than the system in general.

This does decrease overall write throughput, but to the benefit of the latency
of the system as a whole with disk writes.

Other checks may well round this up to 10 still at startup.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm : drop swap cache aggressively

While it may be nice to have a copy of pages on swap once written there, the
more garbage we leave in the swapspace the slower any further writes and
reads to and from it are. Just free swapcache whenever we can.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: kswapd inherit prio

When kswapd is awoken due to reclaim by a running task, set the priority of
kswapd to that of the calling task thus making memory reclaim cpu activity
affected by nice level.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: minimal swappiness

I've yet to find any desktop workload that benefits from anything higher than
a swappiness as low as possible. Unfortunately setting it to zero can rarely
lead to unexplained stalls in the VM so use 10.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>