From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Nazarewicz <mina86@mina86.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Christoph Lameter <cl@linux.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner
Date: Fri, 19 Jun 2015 14:58:20 +0100 [thread overview]
Message-ID: <20150619135820.GC11809@suse.de> (raw)
In-Reply-To: <1433928754-966-5-git-send-email-vbabka@suse.cz>
On Wed, Jun 10, 2015 at 11:32:32AM +0200, Vlastimil Babka wrote:
> The compaction migrate scanner tries to skip compound pages by their order, to
> reduce number of iterations for pages it cannot isolate. The check is only done
> if PageLRU() is true, which means it applies to THP pages, but not e.g.
> hugetlbfs pages or any other non-LRU compound pages, which we have to iterate
> by base pages.
>
> This limitation comes from the assumption that it's only safe to read
> compound_order() when we have the zone's lru_lock and THP cannot be split under
> us. But the only danger (after filtering out order values that are not below
> MAX_ORDER, to prevent overflows) is that we skip too much or too little after
> reading a bogus compound_order() due to a rare race. This is the same reasoning
> as patch 99c0fd5e51c4 ("mm, compaction: skip buddy pages by their order in the
> migrate scanner") introduced for unsafely reading PageBuddy() order.
>
> After this patch, all pages are tested for PageCompound() and we skip them by
> compound_order(). The test is done after the test for balloon_page_movable()
> as we don't want to assume if balloon pages (or other pages with own isolation
> and migration implementation if a generic API gets implemented) are compound
> or not.
>
> When tested with stress-highalloc from mmtests on 4GB system with 1GB hugetlbfs
> pages, the vmstat compact_migrate_scanned count decreased by 15%.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Nazarewicz <mina86@mina86.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Christoph Lameter <cl@linux.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner
Date: Fri, 19 Jun 2015 14:58:20 +0100 [thread overview]
Message-ID: <20150619135820.GC11809@suse.de> (raw)
In-Reply-To: <1433928754-966-5-git-send-email-vbabka@suse.cz>
On Wed, Jun 10, 2015 at 11:32:32AM +0200, Vlastimil Babka wrote:
> The compaction migrate scanner tries to skip compound pages by their order, to
> reduce number of iterations for pages it cannot isolate. The check is only done
> if PageLRU() is true, which means it applies to THP pages, but not e.g.
> hugetlbfs pages or any other non-LRU compound pages, which we have to iterate
> by base pages.
>
> This limitation comes from the assumption that it's only safe to read
> compound_order() when we have the zone's lru_lock and THP cannot be split under
> us. But the only danger (after filtering out order values that are not below
> MAX_ORDER, to prevent overflows) is that we skip too much or too little after
> reading a bogus compound_order() due to a rare race. This is the same reasoning
> as patch 99c0fd5e51c4 ("mm, compaction: skip buddy pages by their order in the
> migrate scanner") introduced for unsafely reading PageBuddy() order.
>
> After this patch, all pages are tested for PageCompound() and we skip them by
> compound_order(). The test is done after the test for balloon_page_movable()
> as we don't want to assume if balloon pages (or other pages with own isolation
> and migration implementation if a generic API gets implemented) are compound
> or not.
>
> When tested with stress-highalloc from mmtests on 4GB system with 1GB hugetlbfs
> pages, the vmstat compact_migrate_scanned count decreased by 15%.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
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:[~2015-06-19 13:58 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 9:32 [PATCH 0/6] Assorted compaction cleanups and optimizations Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-10 9:32 ` [PATCH 1/6] mm, compaction: more robust check for scanners meeting Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-10 18:02 ` Rik van Riel
2015-06-10 18:02 ` Rik van Riel
2015-06-12 9:55 ` Michal Nazarewicz
2015-06-12 9:55 ` Michal Nazarewicz
2015-06-16 5:37 ` Joonsoo Kim
2015-06-16 5:37 ` Joonsoo Kim
2015-06-19 13:41 ` Mel Gorman
2015-06-19 13:41 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 2/6] mm, compaction: simplify handling restart position in free pages scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-16 5:38 ` Joonsoo Kim
2015-06-16 5:38 ` Joonsoo Kim
2015-06-19 13:48 ` Mel Gorman
2015-06-19 13:48 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 3/6] mm, compaction: encapsulate resetting cached scanner positions Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:07 ` Michal Nazarewicz
2015-06-12 10:07 ` Michal Nazarewicz
2015-06-16 5:41 ` Joonsoo Kim
2015-06-16 5:41 ` Joonsoo Kim
2015-06-16 12:13 ` Vlastimil Babka
2015-06-16 12:13 ` Vlastimil Babka
2015-06-10 9:32 ` [PATCH 4/6] mm, compaction: always skip compound pages by order in migrate scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:11 ` Michal Nazarewicz
2015-06-12 10:11 ` Michal Nazarewicz
2015-06-16 5:44 ` Joonsoo Kim
2015-06-16 5:44 ` Joonsoo Kim
2015-06-16 12:16 ` Vlastimil Babka
2015-06-16 12:16 ` Vlastimil Babka
2015-06-19 13:58 ` Mel Gorman [this message]
2015-06-19 13:58 ` Mel Gorman
2015-06-10 9:32 ` [PATCH 5/6] mm, compaction: skip compound pages by order in free scanner Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-12 10:18 ` Michal Nazarewicz
2015-06-12 10:18 ` Michal Nazarewicz
2015-06-16 5:45 ` Joonsoo Kim
2015-06-16 5:45 ` Joonsoo Kim
2015-06-10 9:32 ` [PATCH 6/6] mm, compaction: decouple updating pageblock_skip and cached pfn Vlastimil Babka
2015-06-10 9:32 ` Vlastimil Babka
2015-06-16 6:10 ` Joonsoo Kim
2015-06-16 6:10 ` Joonsoo Kim
2015-06-16 12:33 ` Vlastimil Babka
2015-06-16 12:33 ` Vlastimil Babka
2015-06-16 13:03 ` Joonsoo Kim
2015-06-16 13:03 ` Joonsoo 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=20150619135820.GC11809@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--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.