sched: Limit setaffinity with CPU_HOTPLUG

Some applications do not count CPU's correctly and make bad
decisions on systems with hotplugged CPU's.

Limit app's ability to use setaffinity based on CONFIG_CPU_HOTPLUG.

Change-Id: I133cff0c0c71553ca1febfb044dba59bda38cb33
Signed-off-by: Chris Fries <C.Fries@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/528092
SLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
ARM: smp: Wait just 1 second for other CPU to halt

Currently, the busyloop waiting for a 2nd CPU to stop takes about 4
seconds.  Adjust for the overhead of the loop by looping every 1ms
instead of 1us.

Change-Id: If04a4dc16425fff3898233eea2a0fff95f5db287
Signed-off-by: Chris Fries <C.Fries@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/537864
SLT-Approved: 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: Igor Kovalenko <cik009@motorola.com>
Reviewed-by: Russell Knize <rknize2@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
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)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: compaction: compact normal zone

Compact normal zone when system run into early suspend.

There isn't need to compact other zones since there isn't
big memory block needs in those zones on our platform.

This is ported from the following patch:

 * (CR) compact normal zone only in early suspend
   Reviewed-on: http://gerrit.pcs.mot.com/494963

Change-Id: If81d1d440a365bd54a6bd6d23ef851493280692c
Signed-off-by: Yi-wei Zhao <gbjc64@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/507168
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Jason Hrycay <jason.hrycay@motorola.com>
(cherry picked from commit a8cb0d740ddbe26511f280b958d6c6b41e7bb7e2)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
compact all zones on earlysuspend

mm: compaction: add Android-specific hook.

On larger memory configurations the bulk of memory is in the high
zone and in the 3.4 Android kernels ION and KGSL attempt to make
large allocations. So it's no longer enough to compact just normal
zone. That simplifies things by removing the need for some code.
The suitability of compaction per zone is checked implicitly, so we
will only do anything "expensive" when there's a good reason. Given
that the screen is off at that time, user won't notice anything.
This takes about 150ms on 2GB configuration with MSM8960pro CPU.

Also the code added previously to install earlysuspend handler
was not properly checking for CONFIG_HAS_EARLYSUSPEND, which means
Android-specific code has been stuffed into generic kernel code.
Fix that too, while we're at it.

Change-Id: Icd7b5ec3a304d47611602bdac3e2aad6f4faf8c1
Signed-off-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/522737
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit 88cdf7ab16589afff4f72226980541e15816c8f4)

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: compaction: do suspend compaction in workqueue

Move compact_nodes_suspend out of the direct early suspend workqueue
to avoid long delays in the suspend path on a heavily loaded system;
examples being heavily use of filesystem contending with the pages
that are trying to be compacted.

Signed-off-by: Yuan Jiangli <jlyuan@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/535748
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Christopher Fries <qcf001@motorola.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>

(cherry-pick from commit  6e202c2572708430f682987b2240eae50dadb1e3)

Change-Id: Ifcf8e0ff8f60d3c7f099d95653a43ba9651eeb28
Reviewed-on: http://gerrit.pcs.mot.com/540977
SLT-Approved: 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>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: page_alloc: retry direct compaction

When system load is heavy, memory commpaction may encounter
transient failure; add retry mechanism. And add the following
statistic variable "compact_retry_success" in /proc/vmstat
to see how many compaction success due to the retry.

And __zone_watermark_ok() will easily return false when system
is busy, which will make compaction failure as well. Amend some
to save margin cases.

This patch is ported from the patch:
 * (CR) mem compaction enhancement
   Reviewed-on: http://gerrit.pcs.mot.com/494962

Change-Id: I049a29542926d94f78c723278a711bbf6a87b4a1
Signed-off-by: Yi-wei Zhao <gbjc64@motorola.com>

Conflicts:

	mm/page_alloc.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
hwrng: add randomness to system from rng sources

When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>

Conflicts:
	drivers/char/hw_random/core.c
msm: bam_dmux: UL inactivity timeout is too high

Reduce UL_TIMEOUT from 1000 ms to 200 ms to improve current drain
for idle use case.

Change-Id: I83eba12e28506735ff15f52533dda653872fc9f2
Signed-off-by: Alexander Filonenko <vtp684@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/538334
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Connie Zhao <czhao1@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-by: Christopher Fries <c.fries@motorola.com>
SLT-Approved: Christopher Fries <c.fries@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Delay UL powerdown if BAM is in polling mode

Change-Id: I982c669863390d5ea828d8dd3158e76dab3163e9
Reviewed-on: http://gerrit.pcs.mot.com/548359
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Igor Kovalenko <cik009@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Alexander Filonenko <alexf@motorola.com>
SLT-Approved: Christopher Fries <c.fries@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
msm: bam_dmux: optimize UL inactivity timeout

Increase UL_TIMEOUT_DELAY to 300 ms to avoid most of powerdown attempts while
in polling mode.

Change-Id: Ibbcf641caac492357f78c1d6fd378609ea546c67
Signed-off-by: Alexander Filonenko <vtp684@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/548732
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: Igor Kovalenko <cik009@motorola.com>
SLT-Approved: Christopher Fries <c.fries@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
msm: bam_dmux: fix compilation issue
Change-Id: Ie4dd92ce622a1e59bd415b0d8ba25c1896b20fab
Signed-off-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
[ljc: also call BUG instead of panic]
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
msm: bam_dmux: Use power efficient workqueues for delayed timeouts
There is no need to use a normal per-CPU workqueue for delayed power downs
as they're not timing or performance critical and waking up a core for them
would defeat some of the point.

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
softirq: reduce latencies

In various network workloads, __do_softirq() latencies can be up
to 20 ms if HZ=1000, and 200 ms if HZ=100.

This is because we iterate 10 times in the softirq dispatcher,
and some actions can consume a lot of cycles.

This patch changes the fallback to ksoftirqd condition to :

- A time limit of 2 ms.
- need_resched() being set on current task

When one of this condition is met, we wakeup ksoftirqd for further
softirq processing if we still have pending softirqs.

Using need_resched() as the only condition can trigger RCU stalls,
as we can keep BH disabled for too long.

I ran several benchmarks and got no significant difference in
throughput, but a very significant reduction of latencies (one order
of magnitude) :

In following bench, 200 antagonist "netperf -t TCP_RR" are started in
background, using all available cpus.

Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC
IRQ (hard+soft)

Before patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=550110.424
MIN_LATENCY=146858
MAX_LATENCY=997109
P50_LATENCY=305000
P90_LATENCY=550000
P99_LATENCY=710000
MEAN_LATENCY=376989.12
STDDEV_LATENCY=184046.92

After patch :

# netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
RT_LATENCY=40545.492
MIN_LATENCY=9834
MAX_LATENCY=78366
P50_LATENCY=33583
P90_LATENCY=59000
P99_LATENCY=69000
MEAN_LATENCY=38364.67
STDDEV_LATENCY=12865.26

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>
Cc: Tom Herbert <therbert@google.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Revert "hwrng: add randomness to system from rng sources"

This reverts commit 0692adb1c69fca286dc020fe3ff34f318e07cfb0.