All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>,
	Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>,
	Olaf Hering <olaf@aepfle.de>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions
Date: Wed, 21 Sep 2016 19:18:31 +0200	[thread overview]
Message-ID: <20160921171830.GH24210@dhcp22.suse.cz> (raw)
In-Reply-To: <20160906135258.18335-1-vbabka@suse.cz>

On Tue 06-09-16 15:52:54, Vlastimil Babka wrote:
> After several people reported OOM's for order-2 allocations in 4.7 due to
> Michal Hocko's OOM rework, he reverted the part that considered compaction
> feedback [1] in the decisions to retry reclaim/compaction. This was to provide
> a fix quickly for 4.8 rc and 4.7 stable series, while mmotm had an almost
> complete solution that instead improved compaction reliability.
> 
> This series completes the mmotm solution and reintroduces the compaction
> feedback into OOM decisions. The first two patches restore the state of mmotm
> before the temporary solution was merged, the last patch should be the missing
> piece for reliability. The third patch restricts the hardened compaction to
> non-costly orders, since costly orders don't result in OOMs in the first place.
> 
> Some preliminary testing suggested that this approach should work, but I would
> like to ask all who experienced the regression to please retest this. You will
> need to apply this series on top of tag mmotm-2016-08-31-16-06 from the mmotm
> git tree [2]. Thanks in advance!

We still do not ignore fragindex in the full priority. This part has
always been quite unclear to me so I cannot really tell whether that
makes any difference or not but just to be on the safe side I would
preffer to have _all_ the shortcuts out of the way in the highest
priority. It is true that this will cause COMPACT_NOT_SUITABLE_ZONE
so keep retrying but still a complication to understand the workflow.

What do you think?
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>,
	Ralf-Peter Rohbeck <Ralf-Peter.Rohbeck@quantum.com>,
	Olaf Hering <olaf@aepfle.de>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions
Date: Wed, 21 Sep 2016 19:18:31 +0200	[thread overview]
Message-ID: <20160921171830.GH24210@dhcp22.suse.cz> (raw)
In-Reply-To: <20160906135258.18335-1-vbabka@suse.cz>

On Tue 06-09-16 15:52:54, Vlastimil Babka wrote:
> After several people reported OOM's for order-2 allocations in 4.7 due to
> Michal Hocko's OOM rework, he reverted the part that considered compaction
> feedback [1] in the decisions to retry reclaim/compaction. This was to provide
> a fix quickly for 4.8 rc and 4.7 stable series, while mmotm had an almost
> complete solution that instead improved compaction reliability.
> 
> This series completes the mmotm solution and reintroduces the compaction
> feedback into OOM decisions. The first two patches restore the state of mmotm
> before the temporary solution was merged, the last patch should be the missing
> piece for reliability. The third patch restricts the hardened compaction to
> non-costly orders, since costly orders don't result in OOMs in the first place.
> 
> Some preliminary testing suggested that this approach should work, but I would
> like to ask all who experienced the regression to please retest this. You will
> need to apply this series on top of tag mmotm-2016-08-31-16-06 from the mmotm
> git tree [2]. Thanks in advance!

We still do not ignore fragindex in the full priority. This part has
always been quite unclear to me so I cannot really tell whether that
makes any difference or not but just to be on the safe side I would
preffer to have _all_ the shortcuts out of the way in the highest
priority. It is true that this will cause COMPACT_NOT_SUITABLE_ZONE
so keep retrying but still a complication to understand the workflow.

What do you think?
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2016-09-21 17:18 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 13:52 [PATCH 0/4] reintroduce compaction feedback for OOM decisions Vlastimil Babka
2016-09-06 13:52 ` Vlastimil Babka
2016-09-06 13:52 ` [PATCH 1/4] Revert "mm, oom: prevent premature OOM killer invocation for high order request" Vlastimil Babka
2016-09-06 13:52   ` Vlastimil Babka
2016-09-21 17:04   ` Michal Hocko
2016-09-21 17:04     ` Michal Hocko
2016-09-06 13:52 ` [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority Vlastimil Babka
2016-09-06 13:52   ` Vlastimil Babka
2016-09-21 17:13   ` Michal Hocko
2016-09-21 17:13     ` Michal Hocko
2016-09-22 12:51     ` Vlastimil Babka
2016-09-22 12:51       ` Vlastimil Babka
2016-09-22 14:08       ` Michal Hocko
2016-09-22 14:08         ` Michal Hocko
2016-09-22 14:52         ` Michal Hocko
2016-09-22 14:52           ` Michal Hocko
2016-09-22 14:59           ` Vlastimil Babka
2016-09-22 14:59             ` Vlastimil Babka
2016-09-22 15:06           ` Vlastimil Babka
2016-09-22 15:06             ` Vlastimil Babka
2016-09-23  4:04             ` Hillf Danton
2016-09-23  4:04               ` Hillf Danton
2016-09-23  6:55               ` Vlastimil Babka
2016-09-23  6:55                 ` Vlastimil Babka
2016-09-23  8:23                 ` Michal Hocko
2016-09-23  8:23                   ` Michal Hocko
2016-09-23 10:47                   ` Vlastimil Babka
2016-09-23 10:47                     ` Vlastimil Babka
2016-09-23 12:06                     ` Michal Hocko
2016-09-23 12:06                       ` Michal Hocko
2016-09-06 13:52 ` [PATCH 3/4] mm, compaction: restrict full priority to non-costly orders Vlastimil Babka
2016-09-06 13:52   ` Vlastimil Babka
2016-09-21 17:15   ` Michal Hocko
2016-09-21 17:15     ` Michal Hocko
2016-09-06 13:52 ` [PATCH 4/4] mm, compaction: make full priority ignore pageblock suitability Vlastimil Babka
2016-09-06 13:52   ` Vlastimil Babka
2016-09-15 18:51 ` [PATCH 0/4] reintroduce compaction feedback for OOM decisions Arkadiusz Miskiewicz
2016-09-15 18:51   ` Arkadiusz Miskiewicz
2016-09-21 17:18 ` Michal Hocko [this message]
2016-09-21 17:18   ` Michal Hocko
2016-09-22 15:18   ` Vlastimil Babka
2016-09-22 15:18     ` Vlastimil Babka
2016-09-23  8:26     ` Michal Hocko
2016-09-23  8:26       ` Michal Hocko
2016-09-23 10:55       ` Vlastimil Babka
2016-09-23 10:55         ` Vlastimil Babka
2016-09-23 12:09         ` Michal Hocko
2016-09-23 12:09           ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160921171830.GH24210@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=Ralf-Peter.Rohbeck@quantum.com \
    --cc=a.miskiewicz@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=olaf@aepfle.de \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.