ARM: 7150/1: Allow kernel unaligned accesses on ARMv6+ processors
Revert "drivers: add Contiguous Memory Allocator"

This reverts commit 65a4126f4322682a0023ae5ab10261901bc8bdac.
TCP/IP tweaks
Proportional Rate Reduction for TCP.

This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.

The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
  1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
  2) losses near the end of short flows where application runs out of
data to send.

As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.

A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
    http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
    http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
    http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
    Improving TCP Loss Recovery
    Nandita Dukkipati, Matt Mathis, Yuchung Cheng

Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mohamed Karami <karamimed@gmail.com>

Conflicts:
	net/ipv4/tcp_input.c

Change-Id: I2c4c209cd9d0abbf045386929746976def07faa9
tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample

[ Upstream commit 18a223e0b9ec8979320ba364b47c9772391d6d05 ]

Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and
unscaled RTT samples.

The intent in the code was to only use the 'm' measurement if it was a
new minimum.  However, since 'm' had not yet been shifted left 3 bits
but 'new_sample' had, this comparison would nearly always succeed,
leading us to erroneously set our receive-side RTT estimate to the 'm'
sample when that sample could be nearly 8x too high to use.

The overall effect is to often cause the receive-side RTT estimate to
be significantly too large (up to 40% too large for brief periods in
my tests).

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcp: fix tcp_grow_window() for large incoming frames

[ Upstream commit 4d846f02392a710f9604892ac3329e628e60a230 ]

tcp_grow_window() has to grow rcv_ssthresh up to window_clamp, allowing
sender to increase its window.

tcp_grow_window() still assumes a tcp frame is under MSS, but its no
longer true with LRO/GRO.

This patch fixes one of the performance issue we noticed with GRO on.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: ip_expire() must revalidate route

commit 64f3b9e203bd06855072e295557dca1485a2ecba upstream.

Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
added a bug in IP defragmentation handling, in case timeout is fired.

When a frame is defragmented, we use last skb dst field when building
final skb. Its dst is valid, since we are in rcu read section.

But if a timeout occurs, we take first queued fragment to build one ICMP
TIME EXCEEDED message. Problem is all queued skb have weak dst pointers,
since we escaped RCU critical section after their queueing. icmp_send()
might dereference a now freed (and possibly reused) part of memory.

Calling skb_dst_drop() and ip_route_input_noref() to revalidate route is
the only possible choice.

Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
tcp:len check is unnecessarily devastating, change to WARN_ON

[ Upstream commit 2fceec13375e5d98ef033c6b0ee03943fc460950 ]

All callers are prepared for alloc failures anyway, so this error
can safely be boomeranged to the callers domain without super
bad consequences. ...At worst the connection might go into a state
where each RTO tries to (unsuccessfully) re-fragment with such
a mis-sized value and eventually dies.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
staging: android: lowmemorykiller: select a new task to kill

Under certain circumstances, a process may take time to handle a SIGKILL.
When lowmemkiller is called again shortly after, it would pick the same
process to kill over and over, so that we cann't get free memory for long time.

Solution is to check fatal_signal_pending() on the selected task, and if it's
already pending, select a new task to kill.

Cherry-pick 5e3358093351e5d48e21250e31896b855542f22c
Reviewed-on: http://gerrit.pcs.mot.com/479831

Change-Id: I53445114451ffaba293f3c7174fb0b01ed0d34b6
Signed-off-by: Tianshui Shi <kfp634@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/505410
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
(cherry picked from commit da093001caf06ed2296b4f79c84cc48ce713eac6)
staging: android: lmk: skip if killed by lmk

A task can be selected to kill when it's already exiting. Sending
signal to the task at that state won't set TIF_SIGPENDING for it.
After that, every task including threads in the exiting task itself
running into lmk will compete for the mutex, then spend some time
waiting for the exiting task to release memory or try to send signal
to the same task again.
We want the exiting task to exit as early as possible but it's slowed
down greatly by the mutex and waiting. Skip lmk if current thread
group leader is exiting and is killed by lmk. Also delegate TIF_MEMDIE
to current task.

Change-Id: Id7839b81f183165871976666bfd4e04130a00610
Signed-off-by: Yuanyuan Zhong <zyy@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/584015
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Russell Knize <rknize@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
staging: android: lmk: check TIF directly

When trying to fix that lmk can't kill an exiting task
(commit 895304e926352e0272964a421bd6271e47616ab3
(CR) staging: android: lmk: skip if killed by lmk),
additional check was added for the TIF_MEMDIE flag.
However the task lock has already been taken when examining
the task. The same helper function which tries to grab the
task lock again will be deadlocked.
Change to check the thread flag of thread group leader directly.

Change-Id: If1f880aaca2f053a54ab38c62f275f0a714eb5d2
Signed-off-by: Yuanyuan Zhong <zyy@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/587751
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
android/lowmemorykiller: Account for total_swapcache_pages

The lowmemorykiller relies on NR_FILE_PAGES when measureing
the amount of reclaimable memory in the system.
However when swap is enabled swap cache pages are counted
in NR_FILE_PAGES, and swap cache pages aren't as reclaimable
in low memory as file cache pages. Therefore a large swap
cache can result in the lowmemorykiller not running and
an OOM occuring.

In order to ensure the lowmemorykiller properly evaluates the
amount of reclaimable memory don't count the swap cache pages.

Change-Id: I38239283e572f814b277c718eaf6be7f92abacbb
Signed-off-by: Liam Mark <lmark@codeaurora.org>
readahead: make context readahead more conservative

Try to prevent negatively impact moderately dense random reads on SSD.

Transaction-Per-Second numbers provided by Taobao:

		QPS	case
		-------------------------------------------------------
		7536	disable context readahead totally
w/ patch:	7129	slower size rampup and start RA on the 3rd read
		6717	slower size rampup
w/o patch:	5581	unmodified context readahead
Before, readahead will be started whenever reading page N+1 when it
happen to read N recently. After patch, we'll only start readahead
when *three* random reads happen to access pages N, N+1, N+2. The
probability of this happening is extremely low for pure random reads,
unless they are very dense, which actually deserves some readahead.

Also start with a smaller readahead window. The impact to interleaved
sequential reads should be small, because for a long run stream, the
the small readahead window rampup phase is negletable.

The context readahead actually benefits clustered random reads on HDD
whose seek cost is pretty high.  However as SSD is increasingly used for
random read workloads it's better for the context readahead to
concentrate on interleaved sequential reads.

Tested-by: Tao Ma <tm@tao.ma>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com
Post for review first, will include this in the next readahead series.
ARM: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU
ARM: decompressor: Enable unaligned memory access for v6 and above
Modern GCC can generate code which makes use of the CPU's native
unaligned memory access capabilities.  This is useful for the C
decompressor implementations used for unpacking compressed kernels.

This patch disables alignment faults and enables the v6 unaligned
access model on CPUs which support these features (i.e., v6 and
later), allowing full unaligned access support for C code in the
decompressor.

The decompressor C code must not be built to assume that unaligned
access works if support for v5 or older platforms is included in
the kernel.

For correct code generation, C decompressor code must always use
the get_unaligned and put_unaligned accessors when dealing with
unaligned pointers, regardless of this patch.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>

Conflicts:
	arch/arm/boot/compressed/head.S