From: Minchan Kim <minchan@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [RFC] mm: show deferred_compaction state in page alloc fail
Date: Thu, 25 Sep 2014 10:26:11 +0900 [thread overview]
Message-ID: <20140925012611.GD17364@bbox> (raw)
In-Reply-To: <5422E1B8.9000100@suse.cz>
On Wed, Sep 24, 2014 at 05:22:32PM +0200, Vlastimil Babka wrote:
> On 08/26/2014 09:30 AM, Minchan Kim wrote:
> >Recently, I saw several reports that high order allocation failed
> >although there were many freeable pages but it's hard to reproduce
> >so asking them to reproduce the problem several time is really painful.
> >
> >A culprit I doubt is compaction deferring logic which prevent
> >compaction for a while so high order allocation could be fail.
>
> Could be that, but also the non-determinism of watermark checking,
> where compaction thinks allocation should succeed, but in the end it
> won't.
>
> >It would be more clear if we can see the stat which can show
> >current zone's compaction deferred state when allocatil fail.
> >
> >It's a RFC and never test it. I just get an idea with
> >handling another strange high order allocation fail.
> >Any comments are welcome.
>
> It's quite large patch. Maybe it could be much simpler if you did
> not print just true/false but:
>
> 1) true/false based on zone->compact_considered < defer_limit, ignoring
> zone->compact_order_failed
>
> 2) zone->compact_order_failed value itself
>
> Then you wouldn't need to pass the allocation order around like you do.
> The "allocation failed" message tells you the order which was
> attempted, and then it's easy for the user to compare with the
> reported
> zone->compact_order_failed and decide if the defer status actually
> applies or not.
Actually, I thought about it. The reason I avoid that approach
is I don't want to expose deferring logic internal but now that
I think about it, it was wrong conclusion because show_free_area
already have been exported lots of internal. IOW, without it,
there is not much to investigate the reason.
I will send it.
Thanks for the review, Vlastimil.
>
>
> --
> 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>
--
Kind regards,
Minchan Kim
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [RFC] mm: show deferred_compaction state in page alloc fail
Date: Thu, 25 Sep 2014 10:26:11 +0900 [thread overview]
Message-ID: <20140925012611.GD17364@bbox> (raw)
In-Reply-To: <5422E1B8.9000100@suse.cz>
On Wed, Sep 24, 2014 at 05:22:32PM +0200, Vlastimil Babka wrote:
> On 08/26/2014 09:30 AM, Minchan Kim wrote:
> >Recently, I saw several reports that high order allocation failed
> >although there were many freeable pages but it's hard to reproduce
> >so asking them to reproduce the problem several time is really painful.
> >
> >A culprit I doubt is compaction deferring logic which prevent
> >compaction for a while so high order allocation could be fail.
>
> Could be that, but also the non-determinism of watermark checking,
> where compaction thinks allocation should succeed, but in the end it
> won't.
>
> >It would be more clear if we can see the stat which can show
> >current zone's compaction deferred state when allocatil fail.
> >
> >It's a RFC and never test it. I just get an idea with
> >handling another strange high order allocation fail.
> >Any comments are welcome.
>
> It's quite large patch. Maybe it could be much simpler if you did
> not print just true/false but:
>
> 1) true/false based on zone->compact_considered < defer_limit, ignoring
> zone->compact_order_failed
>
> 2) zone->compact_order_failed value itself
>
> Then you wouldn't need to pass the allocation order around like you do.
> The "allocation failed" message tells you the order which was
> attempted, and then it's easy for the user to compare with the
> reported
> zone->compact_order_failed and decide if the defer status actually
> applies or not.
Actually, I thought about it. The reason I avoid that approach
is I don't want to expose deferring logic internal but now that
I think about it, it was wrong conclusion because show_free_area
already have been exported lots of internal. IOW, without it,
there is not much to investigate the reason.
I will send it.
Thanks for the review, Vlastimil.
>
>
> --
> 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>
--
Kind regards,
Minchan Kim
next prev parent reply other threads:[~2014-09-25 1:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 7:30 [RFC] mm: show deferred_compaction state in page alloc fail Minchan Kim
2014-08-26 7:30 ` Minchan Kim
2014-09-24 15:22 ` Vlastimil Babka
2014-09-24 15:22 ` Vlastimil Babka
2014-09-25 1:26 ` Minchan Kim [this message]
2014-09-25 1:26 ` Minchan Kim
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=20140925012611.GD17364@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@suse.de \
--cc=riel@redhat.com \
--cc=rientjes@google.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 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.