[PATCH] ARM: do not mark CPU 0 as hotpluggable

A quick poll of the ARM platforms that implement CPU Hotplug support
shows that every platform treats CPU 0 as a special case that cannot be
hotplugged.  In fact every platform has identical code for
platform_cpu_die which returns -EPERM in the case of CPU 0.

The user-facing sysfs interfaces should reflect this by not populating
an 'online' entry for CPU 0 at all.  This better reflects reality by
making it clear to users that CPU 0 cannot be hotplugged.

This patch prevents CPU 0 from being marked as hotpluggable on all ARM
platforms during CPU registration.  This in turn prevents the creation
of an 'online' sysfs interface for that CPU.

Signed-off-by: Mike Turquette <mturquette at ti.com>
---
mm: slub: Do not take expensive steps for SLUBs speculative high-order allocations

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations and falls back to lower allocations if they
fail. However, by simply trying to allocate, the caller can enter
compaction or reclaim - both of which are likely to cost more than the
benefit of using high-order pages in SLUB. On a desktop system, two
users report that the system is getting stalled with kswapd using large
amounts of CPU.

This patch prevents SLUB taking any expensive steps when trying to
use high-order allocations. Instead, it is expected to fall back to
smaller orders more aggressively. Testing from users was somewhat
inconclusive on how much this helped but local tests showed it made
a positive difference. It makes sense that falling back to order-0
allocations is faster than entering compaction or direct reclaim.

Signed-off-yet: Mel Gorman <mgorman@xxxxxxx>
---
mm/page_alloc.c | 3 ++-
mm/slub.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
fs: jbd2: backport from aosp-common-3.4-kernel

Conflicts:
	fs/ext4/super.c