From: Michal Hocko <mhocko@kernel.org>
To: Joonsoo Kim <js1304@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0.14] oom detection rework v6
Date: Tue, 10 May 2016 11:44:48 +0200 [thread overview]
Message-ID: <20160510094448.GI23576@dhcp22.suse.cz> (raw)
In-Reply-To: <CAAmzW4Nb+rV88+YbD+xHDVbOfu_3HpiTVQFy6CgXAoFhpD_+pA@mail.gmail.com>
On Tue 10-05-16 17:00:08, Joonsoo Kim wrote:
> 2016-05-10 16:09 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
> > On 05/10/2016 08:41 AM, Joonsoo Kim wrote:
> >>
> >> You applied band-aid for CONFIG_COMPACTION and fixed some reported
> >> problem but it is also fragile. Assume almost pageblock's skipbit are
> >> set. In this case, compaction easily returns COMPACT_COMPLETE and your
> >> logic will stop retry. Compaction isn't designed to report accurate
> >> fragmentation state of the system so depending on it's return value
> >> for OOM is fragile.
> >
> >
> > Guess I'll just post a RFC now, even though it's not much tested...
>
> I will look at it later. But, I'd like to say something first.
> Even if compaction returns more accurate fragmentation states, it's not a good
> idea to depend on compaction's result to decide OOM. We have reclaimable but
> not migratable pages. Depending on compaction's result cannot deal
> with this case.
>
> For example, please assume that all of the system memory are filled
> with THP pages
> or reclaimable slab pages. They cannot be migrated but we can reclaim them.
Direct reclaim should break those THP pages or shrink those slabs. And
we make sure to reclaim before we consider final call for fail from
compaction feedback. If this is a vast majority of memory we should hit
it pretty reliably AFAICS.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-05-10 9:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 19:47 Michal Hocko
2016-04-20 19:47 ` [PATCH 01/14] vmscan: consider classzone_idx in compaction_ready Michal Hocko
2016-04-21 3:32 ` Hillf Danton
2016-05-04 13:56 ` Michal Hocko
2016-04-20 19:47 ` [PATCH 02/14] mm, compaction: change COMPACT_ constants into enum Michal Hocko
2016-04-20 19:47 ` [PATCH 03/14] mm, compaction: cover all compaction mode in compact_zone Michal Hocko
2016-04-20 19:47 ` [PATCH 04/14] mm, compaction: distinguish COMPACT_DEFERRED from COMPACT_SKIPPED Michal Hocko
2016-04-21 7:08 ` Hillf Danton
2016-04-20 19:47 ` [PATCH 05/14] mm, compaction: distinguish between full and partial COMPACT_COMPLETE Michal Hocko
2016-04-21 6:39 ` Hillf Danton
2016-04-20 19:47 ` [PATCH 06/14] mm, compaction: Update compaction_result ordering Michal Hocko
2016-04-21 6:45 ` Hillf Danton
2016-04-20 19:47 ` [PATCH 07/14] mm, compaction: Simplify __alloc_pages_direct_compact feedback interface Michal Hocko
2016-04-21 6:50 ` Hillf Danton
2016-04-20 19:47 ` [PATCH 08/14] mm, compaction: Abstract compaction feedback to helpers Michal Hocko
2016-04-21 6:57 ` Hillf Danton
2016-04-28 8:47 ` Vlastimil Babka
2016-04-20 19:47 ` [PATCH 09/14] mm: use compaction feedback for thp backoff conditions Michal Hocko
2016-04-21 7:05 ` Hillf Danton
2016-04-28 8:53 ` Vlastimil Babka
2016-04-28 12:35 ` Michal Hocko
2016-04-29 9:16 ` Vlastimil Babka
2016-04-29 9:28 ` Michal Hocko
2016-04-20 19:47 ` [PATCH 10/14] mm, oom: rework oom detection Michal Hocko
2016-04-20 19:47 ` [PATCH 11/14] mm: throttle on IO only when there are too many dirty and writeback pages Michal Hocko
2016-04-20 19:47 ` [PATCH 12/14] mm, oom: protect !costly allocations some more Michal Hocko
2016-04-21 8:03 ` Hillf Danton
2016-05-04 6:01 ` Joonsoo Kim
2016-05-04 6:31 ` Joonsoo Kim
2016-05-04 8:56 ` Michal Hocko
2016-05-04 14:57 ` Joonsoo Kim
2016-05-04 18:19 ` Michal Hocko
2016-05-04 8:53 ` Michal Hocko
2016-05-04 14:39 ` Joonsoo Kim
2016-05-04 18:20 ` Michal Hocko
2016-04-20 19:47 ` [PATCH 13/14] mm: consider compaction feedback also for costly allocation Michal Hocko
2016-04-21 8:13 ` Hillf Danton
2016-04-20 19:47 ` [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders Michal Hocko
2016-04-21 8:24 ` Hillf Danton
2016-04-28 8:59 ` Vlastimil Babka
2016-04-28 12:39 ` Michal Hocko
2016-05-04 6:27 ` Joonsoo Kim
2016-05-04 9:04 ` Michal Hocko
2016-05-04 15:14 ` Joonsoo Kim
2016-05-04 19:22 ` Michal Hocko
2016-05-04 5:45 ` [PATCH 0.14] oom detection rework v6 Joonsoo Kim
2016-05-04 8:12 ` Vlastimil Babka
2016-05-04 8:32 ` Joonsoo Kim
2016-05-04 8:50 ` Michal Hocko
2016-05-04 8:47 ` Michal Hocko
2016-05-04 14:32 ` Joonsoo Kim
2016-05-04 18:16 ` Michal Hocko
2016-05-10 6:41 ` Joonsoo Kim
2016-05-10 7:09 ` Vlastimil Babka
2016-05-10 8:00 ` Joonsoo Kim
2016-05-10 9:44 ` Michal Hocko [this message]
2016-05-10 9:43 ` Michal Hocko
2016-05-12 2:23 ` Joonsoo Kim
2016-05-12 5:19 ` Joonsoo Kim
2016-05-12 10:59 ` 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=20160510094448.GI23576@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®