Linux 3.4.5

(cherry picked from commit fe67162907a26b0fe9e4437024434fc9485bfd3e)
Linux 3.4.6 - 3.4.10

Conflicts:
	arch/arm/configs/mxs_defconfig

(cherry picked from commit c8e0a035ba9227c3c98a4fc8f6ed9f47bd7ff4e7)
Linux 3.4.11

(cherry picked from commit 8e500b707bc5864f98877bc0cd76a303b93fcdfe)
block,elevator: use new hashtable implementation

Switch elevator to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the elevator.

This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.

This patch depends on d9b482c ("hashtable: introduce a small and naive
hashtable") which was merged in v3.6.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit d27ccaf2fc84a8eeb58738c4729fa256a5cfed37)
block: recursive merge requests

In a workload, thread 1 accesses a, a+2, ..., thread 2 accesses a+1, a+3,....
When the requests are flushed to queue, a and a+1 are merged to (a, a+1), a+2
and a+3 too to (a+2, a+3), but (a, a+1) and (a+2, a+3) aren't merged.

If we do recursive merge for such interleave access, some workloads throughput
get improvement. A recent worload I'm checking on is swap, below change
boostes the throughput around 5% ~ 10%.

Signed-off-by: Shaohua Li <shli@fusionio.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
(cherry picked from commit d94151f8c5d0e6966313914c1b3ad4031cd02970)
ext4: remove warning

(cherry picked from commit 55c43f0e09caeebb52e541d0e0adf86ecb0f7f73)
Revert "The Ultra Kernel Samepage Merging feature"

This reverts commit 98ece8bf0ace58ee847b2c29f15fbe74e5f32faf.
Fix char: random

Conflicts:
	arch/arm/configs/cyanogenmod_m4_defconfig

(cherry picked from commit b810c7380976b8e2ffa0b79e16df50a426506bfb)
hashtable: introduce a small and naive hashtable

This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
[ Merging this now, so that subsystems can start applying Sasha's
  patches that use this   - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit 9c586a9fc1052eba3d8dfded0a588fd08862e793)
zram: Disable allocation failure logging

Disable the logging of errors when allocations fail
for zram pages. This avoid excessive logging when system is
very low on memory.

Change-Id: Ifabcf8f1b9c3e3717599d6a0a924f7b2061f00ea
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
(cherry picked from commit 01bb6f4f19121f22aca2f0083b778188aae2be8c)
zram: Change ratio to 90% for bad compress

Change the ratio for determining whether or not we should store
pages as uncompressed in zram. This will allow zram to fit more
data since more of the pages will be stored as compressed.

Change-Id: I37170cafff7e8a4cc44f1622fe52a6cbff85f218
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
(cherry picked from commit dc6313f8777bfbb20164024fd07558eb2181d74f)
staging: zram: Rate limit memory allocation errors

If an error occurs allocating memory for zram we will not be able
to fullfill the request to store the page in zram. The swap subsystem
still continues to try to swap out pages to zram even when this error
occurs since there is currently no facility to stop the swap subsystem
from swapping out during such errors. This can cause the system to be
overflowed with logging errors.

Reduce the amount of logging to prevent the kernel log
from being filled with these error messages.

Change-Id: I54b920337749ece59d9ca78fa8b29345ec7b976b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
(cherry picked from commit ec2dd9ef6a548971dd7a9dff7bfe0f980f2b0041)
staging: zsmalloc: Ensure handle is never 0 on success

zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.

This issue affects all current and future SoCs with physical
memory starting at 0x0. All MSM8974 SoCs which includes
Google Nexus 5 devices are affected.

To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.

Change-Id: I5ad31712be4dd5105ebee81fa95927039c0f6935
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
(cherry picked from commit aff221896fe25f483e243694e7cececf0b16ad02)