fs: Tweak mount options for all partitions

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: separate perf-events definition

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Backport 3.6/3.7 kernel workqueue change to 3.4
play with flags
debug: make the Kernel leaner - picked from @morfic

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	Makefile
	kernel/sched/Makefile
	kernel/trace/Kconfig
Makefile: solve ftrace compilation with Linaro
moar defconfig update
block: row: add magic values.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

These values are applicable for 100 HZ device.
Check http://ripke.com/loadavg/moire for more details.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
staging: android: Fix three checkpatch issues in binder.c

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
staging: android: Lower reserved logger RAM

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
sched: scale cpu load for judgment of group imbalance

Date	Mon, 17 Jun 2013 21:00:24 +0800

We cannot compare two load directly from two cpus, since the cpu power
over two cpu may vary largely.

Suppose we meet such two kind of cpus.
CPU A:
	No real time work, and there are 3 task, with rq->load.weight
being 512.
CPU B:
	Has real time work, and it take 3/4 of the cpu power, which
makes CFS only take 1/4, that is 1024/4=256 cpu power. And over its CFS
runqueue, there is only one task with weight as 128.

Since both cpu's CFS task take for half of the CFS's cpu power, it
should be considered as balanced in such case.

But original judgment like:
        if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
            (max_nr_running - min_nr_running) > 1)
It makes (512-128)>=((512+128)/4), and lead to imbalance conclusion...
Make the load as scaled, to avoid such case.

Signed-off-by: Lei Wen <leiwen@marvell.com>

modified for Mako kernel from LKML reference
Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	kernel/sched/fair.c
arm: Add architecture details

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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*******>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
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*******>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
binfmt_elf.c: use get_random_int() to fix entropy depleting

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm8974: Reduce dma latency to 50 microsec

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
staging: lmk: Fine tune OOM for screen on/off

* Increase no. of parmeters handled by minfree
* Add interface to set different OOM values for screen on/off
* Add parameter to turn on/off auto set of different OOM values

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	drivers/staging/android/lowmemorykiller.c
ARM: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs

DCACHE_WORD_ACCESS uses the word-at-a-time API for optimised string
comparisons in the vfs layer.

This patch implements support for load_unaligned_zeropad for ARM CPUs
with native support for unaligned memory accesses (v6+) when running
little-endian.

Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
rwsem-spinlock: Implement writer lock-stealing for better scalability

We (Linux Kernel Performance project) found a regression
introduced by commit:

  5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem

which converted all anon_vma::mutex locks rwsem write locks.

The semantics are the same, but the behavioral difference is
quite huge in some cases. After investigating it we found the
root cause: mutexes support lock stealing while rwsems don't.

Here is the link for the detailed regression report:

  https://lkml.org/lkml/2013/1/29/84

Ingo suggested adding write lock stealing to rwsems:

    "I think we should allow lock-steal between rwsem writers - that
     will not hurt fairness as most rwsem fairness concerns relate to
     reader vs. writer fairness"

And here is the rwsem-spinlock version.

With this patch, we got a double performance increase in one
test box with following aim7 workfile:

    FILESIZE: 1M
    POOLSIZE: 10M
    10 fork_test

 /usr/bin/time output w/o patch                       /usr/bin/time_output with patch
 -- Percent of CPU this job got: 369%                 Percent of CPU this job got: 537%
 Voluntary context switches: 640595016                Voluntary context switches: 157915561

We got a 45% increase in CPU usage and saved about 3/4 voluntary context switches.

Reported-by: LKP project <lkp@linux.intel.com>
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Alex Shi <alex.shi@intel.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Anton Blanchard <anton@samba.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: paul.gortmaker@windriver.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>