Groups > linux.kernel > #1383701 > unrolled thread

[PATCH 0.14] oom detection rework v6

Started by	Michal Hocko <mhocko@kernel.org>
First post	2016-04-20 21:50 +0200
Last post	2016-05-12 13:10 +0200
Articles	20 on this page of 52 — 5 participants

Back to article view | Back to linux.kernel

  [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 03/14] mm, compaction: cover all compaction mode in compact_zone Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 10/14] mm, oom: rework oom detection Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Vlastimil Babka <vbabka@suse.cz> - 2016-04-28 11:00 +0200
        Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Michal Hocko <mhocko@kernel.org> - 2016-04-28 14:40 +0200
      Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 08:30 +0200
        Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:10 +0200
          Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Joonsoo Kim <js1304@gmail.com> - 2016-05-04 17:20 +0200
            Re: [PATCH 14/14] mm, oom, compaction: prevent from  should_compact_retry looping for ever for costly orders Michal Hocko <mhocko@kernel.org> - 2016-05-04 21:30 +0200
    [PATCH 11/14] mm: throttle on IO only when there are too many dirty and writeback pages Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 08:10 +0200
        Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 08:40 +0200
          Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:00 +0200
            Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Joonsoo Kim <js1304@gmail.com> - 2016-05-04 17:00 +0200
              Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko <mhocko@kernel.org> - 2016-05-04 20:20 +0200
        Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:00 +0200
          Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Joonsoo Kim <js1304@gmail.com> - 2016-05-04 16:40 +0200
            Re: [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko <mhocko@kernel.org> - 2016-05-04 20:30 +0200
    [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-04-21 06:40 +0200
      Re: [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready Michal Hocko <mhocko@kernel.org> - 2016-05-04 16:00 +0200
    [PATCH 05/14] mm, compaction: distinguish between full and partial COMPACT_COMPLETE Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 05/14] mm, compaction: distinguish between full and partial COMPACT_COMPLETE "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-04-21 08:40 +0200
    [PATCH 08/14] mm, compaction: Abstract compaction feedback to helpers Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 08/14] mm, compaction: Abstract compaction feedback to  helpers Vlastimil Babka <vbabka@suse.cz> - 2016-04-28 10:50 +0200
    [PATCH 09/14] mm: use compaction feedback for thp backoff conditions Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
      Re: [PATCH 09/14] mm: use compaction feedback for thp backoff conditions "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2016-04-21 09:10 +0200
      Re: [PATCH 09/14] mm: use compaction feedback for thp backoff  conditions Vlastimil Babka <vbabka@suse.cz> - 2016-04-28 11:00 +0200
        Re: [PATCH 09/14] mm: use compaction feedback for thp backoff  conditions Michal Hocko <mhocko@kernel.org> - 2016-04-28 14:40 +0200
          Re: [PATCH 09/14] mm: use compaction feedback for thp backoff  conditions Vlastimil Babka <vbabka@suse.cz> - 2016-04-29 11:20 +0200
            Re: [PATCH 09/14] mm: use compaction feedback for thp backoff  conditions Michal Hocko <mhocko@kernel.org> - 2016-04-29 11:30 +0200
    [PATCH 13/14] mm: consider compaction feedback also for costly allocation Michal Hocko <mhocko@kernel.org> - 2016-04-20 21:50 +0200
    [PATCH 04/14] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED Michal Hocko <mhocko@kernel.org> - 2016-04-20 22:00 +0200
    [PATCH 02/14] mm, compaction: change COMPACT_ constants into enum Michal Hocko <mhocko@kernel.org> - 2016-04-20 22:00 +0200
    Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 07:50 +0200
      Re: [PATCH 0.14] oom detection rework v6 Vlastimil Babka <vbabka@suse.cz> - 2016-05-04 10:20 +0200
        Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-04 10:40 +0200
        Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-04 11:00 +0200
      Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-04 10:50 +0200
        Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <js1304@gmail.com> - 2016-05-04 16:40 +0200
          Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-04 20:20 +0200
            Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <js1304@gmail.com> - 2016-05-10 08:50 +0200
              Re: [PATCH 0.14] oom detection rework v6 Vlastimil Babka <vbabka@suse.cz> - 2016-05-10 09:10 +0200
                Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <js1304@gmail.com> - 2016-05-10 10:10 +0200
                  Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-10 11:50 +0200
              Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-10 11:50 +0200
                Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-12 04:30 +0200
                  Re: [PATCH 0.14] oom detection rework v6 Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-05-12 07:20 +0200
                  Re: [PATCH 0.14] oom detection rework v6 Michal Hocko <mhocko@kernel.org> - 2016-05-12 13:10 +0200

Page 1 of 3 [1] 2 3 Next page →

#1383701 — [PATCH 0.14] oom detection rework v6

From	Michal Hocko <mhocko@kernel.org>
Date	2016-04-20 21:50 +0200
Subject	[PATCH 0.14] oom detection rework v6
Message-ID	<rq6im-4F2-9@gated-at.bofh.it>

Hi,

This is v6 of the series. The previous version was posted [1]. The
code hasn't changed much since then. I have found one old standing
bug (patch 1) which just got much more severe and visible with this
series. Other than that I have reorganized the series and put the
compaction feedback abstraction to the front just in case we find out
that parts of the series would have to be reverted later on for some
reason. The premature oom killer invocation reported by Hugh [2] seems
to be addressed.

We have discussed this series at LSF/MM summit in Raleigh and there
didn't seem to be any concerns/objections to go on with the patch set
and target it for the next merge window.

Motivation:
As pointed by Linus [3][4] relying on zone_reclaimable as a way to
communicate the reclaim progress is rater dubious. I tend to agree,
not only it is really obscure, it is not hard to imagine cases where a
single page freed in the loop keeps all the reclaimers looping without
getting any progress because their gfp_mask wouldn't allow to get that
page anyway (e.g. single GFP_ATOMIC alloc and free loop). This is rather
rare so it doesn't happen in the practice but the current logic which we
have is rather obscure and hard to follow a also non-deterministic.

This is an attempt to make the OOM detection more deterministic and
easier to follow because each reclaimer basically tracks its own
progress which is implemented at the page allocator layer rather spread
out between the allocator and the reclaim. The more on the implementation
is described in the first patch.

I have tested several different scenarios but it should be clear that
testing OOM killer is quite hard to be representative. There is usually
a tiny gap between almost OOM and full blown OOM which is often time
sensitive. Anyway, I have tested the following 2 scenarios and I would
appreciate if there are more to test.

Testing environment: a virtual machine with 2G of RAM and 2CPUs without
any swap to make the OOM more deterministic.

1) 2 writers (each doing dd with 4M blocks to an xfs partition with 1G
file size, removes the files and starts over again) running in
parallel for 10s to build up a lot of dirty pages when 100 parallel
mem_eaters (anon private populated mmap which waits until it gets
signal) with 80M each.

This causes an OOM flood of course and I have compared both patched
and unpatched kernels. The test is considered finished after there
are no OOM conditions detected. This should tell us whether there are
any excessive kills or some of them premature (e.g. due to dirty pages):

I have performed two runs this time each after a fresh boot.

* base kernel
$ grep "Out of memory:" base-oom-run1.log | wc -l
78
$ grep "Out of memory:" base-oom-run2.log | wc -l
78

$ grep "Kill process" base-oom-run1.log | tail -n1
[ 91.391203] Out of memory: Kill process 3061 (mem_eater) score 39 or sacrifice child
$ grep "Kill process" base-oom-run2.log | tail -n1
[ 82.141919] Out of memory: Kill process 3086 (mem_eater) score 39 or sacrifice child

$ grep "DMA32 free:" base-oom-run1.log | sed 's@.*free:$[0-9]*$kB.*@\1@' | calc_min_max.awk
min: 5376.00 max: 6776.00 avg: 5530.75 std: 166.50 nr: 61
$ grep "DMA32 free:" base-oom-run2.log | sed 's@.*free:$[0-9]*$kB.*@\1@' | calc_min_max.awk
min: 5416.00 max: 5608.00 avg: 5514.15 std: 42.94 nr: 52

$ grep "DMA32.*all_unreclaimable? no" base-oom-run1.log | wc -l
1
$ grep "DMA32.*all_unreclaimable? no" base-oom-run2.log | wc -l
3

* patched kernel
$ grep "Out of memory:" patched-oom-run1.log | wc -l
78
miso@tiehlicka /mnt/share/devel/miso/kvm $ grep "Out of memory:" patched-oom-run2.log | wc -l
77

e grep "Kill process" patched-oom-run1.log | tail -n1
[ 497.317732] Out of memory: Kill process 3108 (mem_eater) score 39 or sacrifice child
$ grep "Kill process" patched-oom-run2.log | tail -n1
[ 316.169920] Out of memory: Kill process 3093 (mem_eater) score 39 or sacrifice child

$ grep "DMA32 free:" patched-oom-run1.log | sed 's@.*free:$[0-9]*$kB.*@\1@' | calc_min_max.awk
min: 5420.00 max: 5808.00 avg: 5513.90 std: 60.45 nr: 78
$ grep "DMA32 free:" patched-oom-run2.log | sed 's@.*free:$[0-9]*$kB.*@\1@' | calc_min_max.awk
min: 5380.00 max: 6384.00 avg: 5520.94 std: 136.84 nr: 77

e grep "DMA32.*all_unreclaimable? no" patched-oom-run1.log | wc -l
2
$ grep "DMA32.*all_unreclaimable? no" patched-oom-run2.log | wc -l
3

The patched kernel run noticeably longer while invoking OOM killer same
number of times. This means that the original implementation is much
more aggressive and triggers the OOM killer sooner. free pages stats
show that neither kernels went OOM too early most of the time, though. I
guess the difference is in the backoff when retries without any progress
do sleep for a while if there is memory under writeback or dirty which
is highly likely considering the parallel IO.
Both kernels have seen races where zone wasn't marked unreclaimable
and we still hit the OOM killer. This is most likely a race where
a task managed to exit between the last allocation attempt and the oom
killer invocation.

2) 2 writers again with 10s of run and then 10 mem_eaters to consume as much
memory as possible without triggering the OOM killer. This required a lot
of tuning but I've considered 3 consecutive runs in three different boots
without OOM as a success.

* base kernel
size=$(awk '/MemFree/{printf "%dK", ($2/10)-(16*1024)}' /proc/meminfo)

* patched kernel
size=$(awk '/MemFree/{printf "%dK", ($2/10)-(12*1024)}' /proc/meminfo)

That means 40M more memory was usable without triggering OOM killer. The
base kernel sometimes managed to handle the same as patched but it
wasn't consistent and failed in at least on of the 3 runs. This seems
like a minor improvement.

I was testing also GPF_REPEAT costly requests (hughetlb) with fragmented
memory and under memory pressure. The results are in patch 11 where the
logic is implemented. In short I can see huge improvement there.

I am certainly interested in other usecases as well as well as any
feedback. Especially those which require higher order requests.

* Changes since v5
- added "vmscan: consider classzone_idx in compaction_ready"
- added "mm, oom, compaction: prevent from should_compact_retry looping
for ever for costly orders"
- acked-bys from Vlastimil
- integrated feedback from review
* Changes since v4
- dropped __GFP_REPEAT for costly allocation as it is now replaced by
the compaction based feedback logic
- !costly high order requests are retried based on the compaction feedback
- compaction feedback has been tweaked to give us an useful information
to make decisions in the page allocator
- rebased on the current mmotm-2016-04-01-16-24 with the previous version
of the rework reverted

* Changes since v3
- factor out the new heuristic into its own function as suggested by
Johannes (no functional changes)

* Changes since v2
- rebased on top of mmotm-2015-11-25-17-08 which includes
wait_iff_congested related changes which needed refresh in
patch#1 and patch#2
- use zone_page_state_snapshot for NR_FREE_PAGES per David
- shrink_zones doesn't need to return anything per David
- retested because the major kernel version has changed since
the last time (4.2 -> 4.3 based kernel + mmotm patches)

* Changes since v1
- backoff calculation was de-obfuscated by using DIV_ROUND_UP
- __GFP_NOFAIL high order migh fail fixed - theoretical bug

[1] http://lkml.kernel.org/r/1459855533-4600-1-git-send-email-mhocko@kernel.org
[2] http://lkml.kernel.org/r/alpine.LSU.2.11.1602241832160.15564@eggly.anvils
[3] http://lkml.kernel.org/r/CA+55aFwapaED7JV6zm-NVkP-jKie+eQ1vDXWrKD=SkbshZSgmw@mail.gmail.com
[4] http://lkml.kernel.org/r/CA+55aFxwg=vS2nrXsQhAUzPQDGb8aQpZi0M7UUh21ftBo-z46Q@mail.gmail.com

[toc] | [next] | [standalone]

#1383702 — [PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface

From	Michal Hocko <mhocko@kernel.org>
Date	2016-04-20 21:50 +0200
Subject	[PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface
Message-ID	<rq6im-4F2-11@gated-at.bofh.it>
In reply to	#1383701

From: Michal Hocko <mhocko@suse.com>

__alloc_pages_direct_compact communicates potential back off by two
variables:
	- deferred_compaction tells that the compaction returned
	  COMPACT_DEFERRED
	- contended_compaction is set when there is a contention on
	  zone->lock resp. zone->lru_lock locks

__alloc_pages_slowpath then backs of for THP allocation requests to
prevent from long stalls. This is rather messy and it would be much
cleaner to return a single compact result value and hide all the nasty
details into __alloc_pages_direct_compact.

This patch shouldn't introduce any functional changes.

Acked-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 mm/page_alloc.c | 67 ++++++++++++++++++++++++++-------------------------------
 1 file changed, 31 insertions(+), 36 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 06af8a757d52..350d13f3709b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2944,29 +2944,21 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
 static struct page *
 __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 		int alloc_flags, const struct alloc_context *ac,
-		enum migrate_mode mode, int *contended_compaction,
-		bool *deferred_compaction)
+		enum migrate_mode mode, enum compact_result *compact_result)
 {
-	enum compact_result compact_result;
 	struct page *page;
+	int contended_compaction;
 
 	if (!order)
 		return NULL;
 
 	current->flags |= PF_MEMALLOC;
-	compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
-						mode, contended_compaction);
+	*compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
+						mode, &contended_compaction);
 	current->flags &= ~PF_MEMALLOC;
 
-	switch (compact_result) {
-	case COMPACT_DEFERRED:
-		*deferred_compaction = true;
-		/* fall-through */
-	case COMPACT_SKIPPED:
+	if (*compact_result <= COMPACT_INACTIVE)
 		return NULL;
-	default:
-		break;
-	}
 
 	/*
 	 * At least in one zone compaction wasn't deferred or skipped, so let's
@@ -2992,6 +2984,24 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 	 */
 	count_vm_event(COMPACTFAIL);
 
+	/*
+	 * In all zones where compaction was attempted (and not
+	 * deferred or skipped), lock contention has been detected.
+	 * For THP allocation we do not want to disrupt the others
+	 * so we fallback to base pages instead.
+	 */
+	if (contended_compaction == COMPACT_CONTENDED_LOCK)
+		*compact_result = COMPACT_CONTENDED;
+
+	/*
+	 * If compaction was aborted due to need_resched(), we do not
+	 * want to further increase allocation latency, unless it is
+	 * khugepaged trying to collapse.
+	 */
+	if (contended_compaction == COMPACT_CONTENDED_SCHED
+		&& !(current->flags & PF_KTHREAD))
+		*compact_result = COMPACT_CONTENDED;
+
 	cond_resched();
 
 	return NULL;
@@ -3000,8 +3010,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 static inline struct page *
 __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
 		int alloc_flags, const struct alloc_context *ac,
-		enum migrate_mode mode, int *contended_compaction,
-		bool *deferred_compaction)
+		enum migrate_mode mode, enum compact_result *compact_result)
 {
 	return NULL;
 }
@@ -3146,8 +3155,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 	unsigned long pages_reclaimed = 0;
 	unsigned long did_some_progress;
 	enum migrate_mode migration_mode = MIGRATE_ASYNC;
-	bool deferred_compaction = false;
-	int contended_compaction = COMPACT_CONTENDED_NONE;
+	enum compact_result compact_result;
 
 	/*
 	 * In the slowpath, we sanity check order to avoid ever trying to
@@ -3245,8 +3253,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 	 */
 	page = __alloc_pages_direct_compact(gfp_mask, order, alloc_flags, ac,
 					migration_mode,
-					&contended_compaction,
-					&deferred_compaction);
+					&compact_result);
 	if (page)
 		goto got_pg;
 
@@ -3259,25 +3266,14 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 		 * to heavily disrupt the system, so we fail the allocation
 		 * instead of entering direct reclaim.
 		 */
-		if (deferred_compaction)
-			goto nopage;
-
-		/*
-		 * In all zones where compaction was attempted (and not
-		 * deferred or skipped), lock contention has been detected.
-		 * For THP allocation we do not want to disrupt the others
-		 * so we fallback to base pages instead.
-		 */
-		if (contended_compaction == COMPACT_CONTENDED_LOCK)
+		if (compact_result == COMPACT_DEFERRED)
 			goto nopage;
 
 		/*
-		 * If compaction was aborted due to need_resched(), we do not
-		 * want to further increase allocation latency, unless it is
-		 * khugepaged trying to collapse.
+		 * Compaction is contended so rather back off than cause
+		 * excessive stalls.
 		 */
-		if (contended_compaction == COMPACT_CONTENDED_SCHED
-			&& !(current->flags & PF_KTHREAD))
+		if(compact_result == COMPACT_CONTENDED)
 			goto nopage;
 	}
 
@@ -3325,8 +3321,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
 	 */
 	page = __alloc_pages_direct_compact(gfp_mask, order, alloc_flags,
 					    ac, migration_mode,
-					    &contended_compaction,
-					    &deferred_compaction);
+					    &compact_result);
 	if (page)
 		goto got_pg;
 nopage:
-- 
2.8.0.rc3

From	Vlastimil Babka <vbabka@suse.cz>
Date	2016-04-28 11:00 +0200
Subject	Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders
Message-ID	<rsPXI-hT-11@gated-at.bofh.it>
In reply to	#1383705

From	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date	2016-05-04 08:30 +0200
Subject	Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders
Message-ID	<ruYtQ-71w-19@gated-at.bofh.it>
In reply to	#1383705

From	Joonsoo Kim <js1304@gmail.com>
Date	2016-05-04 17:20 +0200
Subject	Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders
Message-ID	<rv6KJ-6s5-15@gated-at.bofh.it>
In reply to	#1394105

[PATCH 0.14] oom detection rework v6

Contents

#1383701 — [PATCH 0.14] oom detection rework v6

#1383702 — [PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface

#1383703 — [PATCH 03/14] mm, compaction: cover all compaction mode in compact_zone

#1383704 — [PATCH 10/14] mm, oom: rework oom detection

#1383705 — [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1389896 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1390125 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1394017 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1394105 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1394434 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1394658 — Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders

#1383707 — [PATCH 11/14] mm: throttle on IO only when there are too many dirty and writeback pages

#1383708 — [PATCH 12/14] mm, oom: protect !costly allocations some more

#1393982 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394019 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394099 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394421 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394599 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394095 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more

#1394355 — Re: [PATCH 12/14] mm, oom: protect !costly allocations some more