fs: improve generic fsync

Conflicts:

	fs/libfs.c
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
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>
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>
ASoC: msm: Decrease max volume

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
bcmdhd: tweaked wakelocks a bit

Conflicts:
	drivers/net/wireless/bcmdhd/dhd_linux.c

Change-Id: If234343ce05e5f00f8bf12628b714d547c53fe2f

Conflicts:

	drivers/net/wireless/bcmdhd/dhd_linux.c