From: Minchan Kim <minchan@kernel.org>
To: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>,
Vlastimil Babka <vbabka@suse.cz>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Sangseok Lee <sangseok.lee@lge.com>
Subject: Re: [PATCH v3 3/4] mm: try to exhaust highatomic reserve before the OOM
Date: Thu, 13 Oct 2016 08:39:01 +0900 [thread overview]
Message-ID: <20161012233901.GA30745@bbox> (raw)
In-Reply-To: <20161012083449.GD17128@dhcp22.suse.cz>
Hi Michal,
On Wed, Oct 12, 2016 at 10:34:50AM +0200, Michal Hocko wrote:
> Looks much better. Thanks! I am wondering whether we want to have this
> marked for stable. The patch is quite non-intrusive and fires only when
> we are really OOM. It is definitely better to try harder than go and
> disrupt the system by the OOM killer. So I would add
> Fixes: 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand")
> Cc: stable # 4.4+
Thanks for the information.
>
> The backport will look slightly different for kernels prior 4.6 because
> we do not have should_reclaim_retry yet but the check might hook right
> before __alloc_pages_may_oom.
As I just got one report and I didn't see similar problem in LKML
recently, I didn't mark it to the stable given that patchset size
in v1. However, with review, it becomes simple(Thanks, Michal and
Vlastimil) and I should admit my ladar is too limited so if you think
it's worth, I don't mind.
For the stable, {3,4}/4 are must but once we decide, I want to backport
all patches {1-4}/4 because without {1,2}, nr_reserved_highatomic mismatch
can happen so that unreserve logic doesn't work until force logic is
triggered when no_progress_loops is greater than MAX_RECLAIM_RETRIES.
It happend very easily in my test.
Withtout {1,2}, it works but looks no-good for me.
> --
> 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>
next prev parent reply other threads:[~2016-10-12 23:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 8:03 [PATCH v3 0/4] use up highorder free pages before OOM Minchan Kim
2016-10-12 8:03 ` [PATCH v3 1/4] mm: don't steal highatomic pageblock Minchan Kim
2016-10-12 8:03 ` [PATCH v3 2/4] mm: prevent double decrease of nr_reserved_highatomic Minchan Kim
2016-10-12 8:03 ` [PATCH v3 3/4] mm: try to exhaust highatomic reserve before the OOM Minchan Kim
2016-10-12 8:34 ` Michal Hocko
2016-10-12 23:39 ` Minchan Kim [this message]
2016-10-12 8:03 ` [PATCH v3 4/4] mm: make unreserve highatomic functions reliable Minchan Kim
2016-10-12 8:36 ` 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=20161012233901.GA30745@bbox \
--to=minchan@kernel.org \
--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=mhocko@kernel.org \
--cc=sangseok.lee@lge.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).