staging: android: lowmemorykiller: Reduce debug_level to 1

Under certain circumstances, such as after the lowmemorykiller
has recently killed an application, the logs can get flooded
with "select to kill" messages.

Change-Id: I7ae1de47c77d929e04b99be3432577d4f5fd1b2d
Signed-off-by: Liam Mark <lmark@codeaurora.org>
android/lowmemorykiller: Wait for memory to be freed

The memory reclaim code needs to give time to the system to
return the memory from a killed process otherwise the memory
reclaim code could run continuously, in multiple threads,
which could starve both the watchdog thread and the thread
which is responsible for returning the memory from the
killed process.

Change-Id: I7687a16a1ba7f97259eda976548c810c97e742cc
CRs-fixed: 484900
Signed-off-by: Liam Mark <lmark@codeaurora.org>
[To remove merge conflict]
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
android/lowmemorykiller: Ignore tasks with freed mm

A killed task can stay in the task list long after its
memory has been returned to the system, therefore
ignore any tasks whose mm struct has been freed.

Change-Id: Ib7bb857bd717e150221952b13349adc15e5bafd1
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
android: lowmemorykiller: add lmk parameters tunning code.

There are cases that LMK doesn't run, even when it must run.
It is due to LMK shrinker not considering memory status per zone.
So add LMK parameters(other_free, other_file) tunnig code to
consider target zone of LMK shrinker.

Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d
gpu: ion: Restrict access to CP heap

On certain targets, the CP heap should only be used
for secure allocations. Add a check to determine which
targets are allowed to make non-secure allocations from
the CP heap type. Targets with this restriction will
fall back to an alternate heap.

[lauraa@codeaurora.org: Context conflicts]
(cherry picked from commit 10490fab90087e0f45dd5ace7bc24ba7993c777c)

Change-Id: If19a860e6c103bb14675a1e4313b88fc50393f45
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm: make counts of CMA free pages correct

Both patches needed, second patch (among other things) fixes
a bug in the first.

commit 2139cbe627b8910ded55148f87ee10f7485408ed

    Isolated free pages shouldn't be accounted to NR_FREE_PAGES counter.  Fix
    it by properly decreasing/increasing NR_FREE_PAGES counter in
    set_migratetype_isolate()/unset_migratetype_isolate() and removing counter
    adjustment for isolated pages from free_one_page() and split_free_page().

    [lbassel@codeaurora.org: backport from 3.7, small changes needed]

commit d1ce749a0db12202b711d1aba1d29e823034648d

    Add NR_FREE_CMA_PAGES counter to be later used for checking watermark in
    __zone_watermark_ok().  For simplicity and to avoid #ifdef hell make this
    counter always available (not only when CONFIG_CMA=y).

    [akpm@linux-foundation.org: use conventional migratetype naming]
    [lbassel@codeaurora.org: backport from 3.7, small changes needed]

(cherry picked from commit 6d6e2c9bcfb8174265fc2429aea185c7a452dbd9)

Change-Id: Ib4493002d646a0ebbfff68afe45549127993e831
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Mon Oct 8 16:32:00 2012 -0700
    cma: fix counting of isolated pages
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Michal Nazarewicz <mina86@mina86.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Mon Oct 8 16:32:02 2012 -0700
    cma: count free CMA pages
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Michal Nazarewicz <mina86@mina86.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
mm: Use correct define for CMA features

CMA features may ifdef out parts of the code with
CONFIG_CMA. Older code uses CONFIG_DMA_CMA. Switch
to using the newer CONFIG_CMA to ensure the code gets
compiled when needed.

(cherry picked from commit 6975529f4f8f1477f6e8d469f1260ff767511230)

Change-Id: Ied2807e5a5444f54da28b3a95c9ff50ab484f011
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
gpu: ion: Add flag for forcing contiguous allocations

Previously, a parameter was added to secure heaps to only
allow secure allocations. Some clients still require
non-secure contiguous allocations even though the SMMU is
supported. Add support for those clients to force contiguous
allocations to go through.

Change-Id: I0d18d8a9ed3ab267b55c84c4ad160f8cec2c2b32
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
android/lowmemorykiller: Selectively count free CMA pages

In certain memory configurations there can be a large number of
CMA pages which are not suitable to satisfy certain memory
requests.

This large number of unsuitable pages can cause the
lowmemorykiller to not kill any tasks because the
lowmemorykiller counts all free pages.
In order to ensure the lowmemorykiller properly evaluates the
free memory only count the free CMA pages if they are suitable
for satisfying the memory request.

Change-Id: I7f06d53e2d8cfe7439e5561fe6e5209ce73b1c90
CRs-fixed: 437016
Signed-off-by: Liam Mark <lmark@codeaurora.org>
mm: show migration types in show_mem

This is useful to diagnose the reason for page allocation failure for
cases where there appear to be several free pages.

Example, with this alloc_pages(GFP_ATOMIC) failure:

 swapper/0: page allocation failure: order:0, mode:0x0
 ...
 Mem-info:
 Normal per-cpu:
 CPU    0: hi:   90, btch:  15 usd:  48
 CPU    1: hi:   90, btch:  15 usd:  21
 Normal free:16104kB min:2296kB low:2868kB high:3444kB active_anon:0kB
 isolated(anon):0kB isolated(file):0kB present:331776kB mlocked:0kB
 lowmem_reserve[]: 0 0

Before the patch, it's hard (for me, at least) to say why all these free
chunks weren't considered for allocation:

 1*1024kB 1*2048kB 3*4096kB = 16128kB

After the patch, it's obvious that the reason is that all of these are
in the MIGRATE_CMA (C) freelist:

 (C) 1*1024kB (C) 1*2048kB (C) 3*4096kB (C) = 16128kB

(cherry picked from commit 394b808b232daea1a92c0b41dfc3d3134788ed46)

Change-Id: Ib4924802b89a063c9145522a57319f02d5e938b1
 active_anon:0 inactive_anon:0 isolated_anon:0
  active_file:0 inactive_file:84 isolated_file:0
  unevictable:0 dirty:0 writeback:0 unstable:0
  free:4026 slab_reclaimable:75 slab_unreclaimable:484
  mapped:0 shmem:0 pagetables:0 bounce:0
 inactive_anon:0kB active_file:0kB inactive_file:336kB unevictable:0kB
 dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:300kB
 slab_unreclaimable:1936kB kernel_stack:328kB pagetables:0kB unstable:0kB
 bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB
 Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB (C) 1*512kB
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm: cma: on movable allocations try MIGRATE_CMA first

It has been observed that system tends to keep a lot of CMA free pages
even in very high memory pressure use cases.  The CMA fallback for
movable pages is used very rarely, only when system is completely
pruned from MOVABLE pages.  This means that the out-of-memory is
triggered for unmovable allocations even when there are many CMA pages
available.  This problem was not observed previously since movable
pages were used as a fallback for unmovable allocations.

To avoid such situation this commit changes the allocation order so
that on movable allocations the MIGRATE_CMA pageblocks are used first.

This change means that the MIGRATE_CMA can be removed from fallback
path of the MIGRATE_MOVABLE type.  This means that the
__rmqueue_fallback() function will never deal with CMA pages and thus
all the checks around MIGRATE_CMA can be removed from that function.

(cherry picked from commit b5662d64fa5ee483b985b351dec993402422fee3)

Change-Id: Iaadcb2dd5c8fe870271145c8fe2cf1e130631f15
CRs-Fixed: 435287
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>