block/deadline: tweaked for better performance on android
mmc: host: sdhci: Allow use of controller's native max blocksize

Currently, any controller supporting a blocksize of 4K or higher
is bumped back down to 512 bytes. This change allows using the
controller's native blocksize on a per-hardware basis.
[PATCH] proofs: add num_to_str() to speed up /proc/stat

== stat_check.py
num = 0
with open("/proc/stat") as f:
        while num < 1000 :
                data = f.read()
                f.seek(0, 0)
                num = num + 1
==

perf shows

    20.39%  stat_check.py  [kernel.kallsyms]    [k] format_decode
    13.41%  stat_check.py  [kernel.kallsyms]    [k] number
    12.61%  stat_check.py  [kernel.kallsyms]    [k] vsnprintf
    10.85%  stat_check.py  [kernel.kallsyms]    [k] memcpy
     4.85%  stat_check.py  [kernel.kallsyms]    [k] radix_tree_lookup
     4.43%  stat_check.py  [kernel.kallsyms]    [k] seq_printf

This patch removes most of calls to vsnprintf() by adding num_to_str()
and seq_print_decimal_ull(), which prints decimal numbers without rich
functions provided by printf().

On my 8cpu box.
== Before patch ==
[root@bluextal test]# time ./stat_check.py

real    0m0.150s
user    0m0.026s
sys     0m0.121s

== After patch ==
[root@bluextal test]# time ./stat_check.py

real    0m0.055s
user    0m0.022s
sys     0m0.030s

[akpm@linux-foundation.org: remove incorrect comment, use less statck
in num_to_str(), move comment from .h to .c, simplify
seq_put_decimal_ull()]
[andrea@betterlinux.com: avoid breaking the ABI in /proc/stat]
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrea Righi <andrea@betterlinux.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Turner <pjt@google.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
back ported from Linux 3.4-rc4 to Linux 3.0.x by faux123
[PATCH] sched: fix OOPS when build_sched_domains percpu allocation fails

From: "he, bo" <bo.he@intel.com>

Under extreme memory used up situation, percpu allocation
might fails. We hit it when system go to suspend-to-ram.

EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
SS:ESP 0068:de725d04
CR2: 0000000034811000
---[ end trace d6086359b670b975 ]---
Kernel panic - not syncing: Fatal exception
Pid: 3026, comm: kworker/u:3 Tainted: G      D W
3.0.8-137473-gf42fbef #1
Call Trace:
 [<c18cc4f2>] panic+0x66/0x16c
 [<c12521a1>] ? oops_exit+0x61/0x90
 [<c1205f89>] oops_end+0xb9/0xd0
 [<c1227796>] no_context+0xc6/0x1f0
 [<c1227958>] __bad_area_nosemaphore+0x98/0x140
 [<c1204ebf>] ? dump_trace+0x7f/0xf0
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c1227a17>] bad_area_nosemaphore+0x17/0x20
 [<c1227fa0>] do_page_fault+0x270/0x3c0
 [<c1306afa>] ? pcpu_alloc+0x12ca/0x1300
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c18d09d3>] error_code+0x5f/0x64
 [<c13000d8>] ? shmem_setattr+0x198/0x230
 [<c1227d30>] ? pgtable_bad+0x130/0x130
 [<c124411a>] ? build_sched_domains+0x23a/0xad0
 [<c18d01a6>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c1244c37>] partition_sched_domains+0x287/0x4b0
 [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
 [<c1673017>] ? __cpufreq_remove_dev+0x167/0x360
 [<c18cf03c>] ? down_write+0x1c/0x40
 [<c123712d>] cpuset_cpu_inactive+0x1d/0x30
 [<c127dff2>] notifier_call_chain+0x52/0x90
 [<c127e04e>] __raw_notifier_call_chain+0x1e/0x30
 [<c18b37c9>] _cpu_down+0x89/0x230
 [<c12547f9>] disable_nonboot_cpus+0x79/0x100
 [<c1299fb3>] suspend_devices_and_enter+0x133/0x2e0
 [<c129a27d>] enter_state+0x11d/0x180
 [<c129a307>] pm_suspend+0x27/0x70
 [<c129b8b6>] suspend+0x96/0x1d0
 [<c1271aa3>] process_one_work+0x103/0x400
 [<c129b820>] ? power_suspend_late+0x90/0x90
 [<c12728ac>] worker_thread+0x12c/0x4b0
 [<c123748d>] ? sub_preempt_count+0x3d/0x50
 [<c18d01a6>] ? _raw_spin_unlock_irqrestore+0x26/0x50
 [<c1272780>] ? manage_workers+0x520/0x520
 [<c1276f44>] kthread+0x74/0x80
 [<c1276ed0>] ? __init_kthread_worker+0x30/0x30
 [<c18d113a>] kernel_thread_helper+0x6/0x10
Signed-off-by: he, bo <bo.he@intel.com>
Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
back ported for Linux 3.0 from Linux 3.4+ by faux123
[PATCH] sched/fair: Improve the ->group_imb logic

Group imbalance is meant to deal with situations where affinity masks
and sched domains don't align well, such as 3 cpus from one group and
6 from another. In this case the domain based balancer will want to
put an equal amount of tasks on each side even though they don't have
equal cpus.

Currently group_imb is set whenever two cpus of a group have a weight
difference of at least one avg task and the heaviest cpu has at least
two tasks. A group with imbalance set will always be picked as busiest
and a balance pass will be forced.
The problem is that even if there are no affinity masks this stuff can
trigger and cause weird balancing decisions, eg. the observed
behavior was that of 6 cpus, 5 had 2 and 1 had 3 tasks, due to the
difference of 1 avg load (they all had the same weight) and nr_running
being >1 the group_imbalance logic triggered and did the weird thing
of pulling more load instead of trying to move the 1 excess task to
the other domain of 6 cpus that had 5 cpu with 2 tasks and 1 cpu with
1 task.
Curb the group_imbalance stuff by making the nr_running condition
weaker by also tracking the min_nr_running and using the difference in
nr_running over the set instead of the absolute max nr_running.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link:
http://lkml.kernel.org/n/tip-9s7dedozxo8kjsb9kqlrukkf@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
modified for Linux 3.0 from Linux 3.4+ by faux123
[PATCH] timer: optimize apply_slack()

__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but
cheaper.
find_last_bit was showing up high on the list when I was profiling for
stalls
on cache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
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*******>
sched: disable GENTLTE_FAIR_SLEEPERS for better performance on Android
ARM: entry: no need to increase preempt count for IRQ handlers

From: Russell King <rmk+kernel@arm.linux.org.uk>
Date: Sat, 25 Jun 2011 09:57:57 +0000 (+0100)
Subject: ARM: entry: no need to increase preempt count for IRQ handlers
X-Git-Tag: v3.1-rc1~258^2~1^3~16
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=1613cc1119ecdb1bdb950da53065e615e4c4b8db

irq_enter() and irq_exit() already take care of the preempt_count
handling for interrupts, which increment and decrement the hardirq
bits of the preempt count.  So we can remove the preempt count handing
in our IRQ entry/exit assembly, like x86 did some 9 years ago.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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*******>
mmc: msm_sdcc: Power down slots after reboot

Some reboot methods (eg. adb reboot) may not power
down SDCC slots. This can result in cards being
in unexpected states after reboot. Explicitly reset
slot voltage regulator on reboot.

CRs-Fixed: 341840
Change-Id: I8cdb52bc58e34900378af468794760653f3babad
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
scheduler: minor improvement to pick_next_highest_task_rt

From: Michael J Wang <mjwang@broadcom.com>

Avoid extra work by continuing on to the next rt_rq if the highest prio task
in current rt_rq is the same priority as our candidate task.

Signed-off-by: Michael J Wang <mjwang@broadcom.com>
Google snappy compression/decompression support
(cherry picked from commit a792d66f18a5177f81c33efd0d3233a5004b1ca5)
Implementation of SNAPPY for zram kernel 3.0.y

Conflicts:

	arch/arm/configs/holiday_defconfig
	arch/arm/configs/p999_defconfig
diag: Fix data corruption.

Diag uses krealloc for allocating memory if number of client exceeds 15 as
krealloc doesn't initialize memory to 0 resulting in corruption of data.
This fix initializes the memory after allocation.

CRs-Fixed: 347675
Change-Id: Ide504a18adc2e1fc282c5543ec77818f346e4015
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
(cherry picked from commit 6bac272ef9b64f0830af50f1537aa18017711022)
Input: evdev - Don't hold wake lock when no data is available to user-…

…space

If there is no SYN_REPORT event in the buffer the buffer data is
invisible
to user-space. Thewake lock should not be held in this case.

Change-Id: Idae890ff0da8eb46a2cfce61a95b3a97252551ad
Signed-off-by: Arve Hjønnevåg <arve@android.com>
sched: Cleanup pre_schedule_rt

From: Yong Zhang <yong.zhang0@gmail.com>
Date: Tue, 9 Feb 2010 19:43:59 +0000 (-0500)
Subject: sched: Cleanup pre_schedule_rt
X-Git-Tag: v3.1-rc1~298^2~19^2~3
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=33c3d6c61debcc0d295fe65521cfbc45409936c7

Since [commit 9a897c5a:
sched: RT-balance, replace hooks with pre/post schedule and wakeup methods]
we must call pre_schedule_rt if prev is rt task.
So condition rt_task(prev) is always true and the 'unlikely' declaration is
simply incorrect.

Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
sched: Change pick_next_task_rt from unlikely to likely

From: Steven Rostedt <srostedt@redhat.com>
Date: Mon, 6 Dec 2010 16:28:30 +0000 (-0500)
Subject: sched: Change pick_next_task_rt from unlikely to likely
X-Git-Tag: v3.1-rc1~298^2~19^2~2
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=8e54a2c036d8c47195f094af1628834f4c55844a

The if (unlikely(!rt_rq->rt_nr_running)) test in pick_next_task_rt()
tests if there is another rt task ready to run. If so, then pick it.

In most systems, only one RT task runs at a time most of the time.
Running the branch unlikely annotator profiler on a system doing average
work "running firefox, evolution, xchat, distcc builds, etc", it showed the
following:

 correct incorrect  %        Function                  File              Line
 ------- ---------  -        --------                  ----              ----
  324344 135104992  99 _pick_next_task_rt             sched_rt.c           1064

99% of the time the condition is true. When an RT task schedules out,
it is unlikely that another RT task is waiting to run on that same run queue.

Simply remove the unlikely() condition.

Acked-by: Gregory Haskins <ghaskins@novell.com>
Cc:Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
sched: Remove unlikely() from rt_policy() in sched.c

From: Steven Rostedt <srostedt@redhat.com>
Date: Mon, 6 Dec 2010 19:48:10 +0000 (-0500)
Subject: sched: Remove unlikely() from rt_policy() in sched.c
X-Git-Tag: v3.1-rc1~298^2~19^2~1
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=63f01241176d7cbc976385aec32f0a209b0bc36a

The rt_policy() has an unlikely() that the policy it is checking is
of RT priority (SCHED_FIFO or SCHED_RR).

According to the annotate branch profiler it is incorrect most of the time:

 correct incorrect  %        Function                  File              Line
 ------- ---------  -        --------                  ----              ----
   36667   654674  94 rt_policy                      sched.c              126

This makes sense because the rt_policy() is used by the sched_set_scheduler()
and nice(). Although users may use sys_nice a bit, all RT users use
the sched_set_scheduler() to set their RT priority, including kernel
threads.

The above numbers were from a normal desktop computer running
firefox, evolution, xchat and was part of a distcc compile farm.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
sched: Remove unlikely() from ttwu_post_activation

From: Steven Rostedt <srostedt@redhat.com>
Date: Mon, 6 Dec 2010 22:10:31 +0000 (-0500)
Subject: sched: Remove unlikely() from ttwu_post_activation
X-Git-Tag: v3.1-rc1~298^2~19^2
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=e69c634190dc724ef2d845ace8d783031d3e492e

The unlikely() used in ttwu_post_activation() tests if the rq->idle_stamp
is set. But since this is for a wakeup, and wakeups happen when tasks
block on IO, and blocking tasks on IO may put the system into idle,
this can actually be a common occurence.

Running the annotated branch profiler on an average desktop running
firefox, evolution, xchat and distcc, the report shows:

 correct incorrect  %        Function             File              Line
 ------- ---------  -        --------             ----              ----
34884862 146110926  80 ttwu_post_activation      sched.c            2309

80% of the time, this unlikely is incorrect. Best not to assume what the
result is, and just remove the branch annotation.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>