From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linux-MM <linux-mm@kvack.org>,
David Rientjes <rientjes@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
ying.huang@intel.com, kirill@shutemov.name,
Andrew Morton <akpm@linux-foundation.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/14] mm, compaction: Skip pageblocks with reserved pages
Date: Tue, 18 Dec 2018 08:38:24 +0000 [thread overview]
Message-ID: <20181218083823.GI29005@techsingularity.net> (raw)
In-Reply-To: <b1d38179-4ccf-f34a-dffa-26c7957b8aed@suse.cz>
On Tue, Dec 18, 2018 at 09:08:02AM +0100, Vlastimil Babka wrote:
> On 12/15/18 12:03 AM, Mel Gorman wrote:
> > Reserved pages are set at boot time, tend to be clustered and almost
> > never become unreserved. When isolating pages for migrating, skip
> > the entire pageblock is one PageReserved page is encountered on the
> > grounds that it is highly probable the entire pageblock is reserved.
>
> Agreed, but maybe since it's highly probable and not certain, this
> skipping should not be done on the highest compaction priority?
>
I don't think that's necessary at this time. For the most part, you are
talking about one partial pageblock at best given how the early memory
allocator works so it would only ever be useful for a high-order kernel
allocation. Second, one of compactions primary problems is inefficient
scanning where viable pageblocks are easily skipped over or only partially
scanned which is something I'm still looking at. Lastly, maximum priority
compaction is rarely hit in practice as far as I can tell.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2018-12-18 8:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 23:02 [RFC PATCH 00/14] Increase success rates and reduce latency of compaction v1 Mel Gorman
2018-12-14 23:02 ` [PATCH 01/14] mm, compaction: Shrink compact_control Mel Gorman
2018-12-17 12:27 ` Vlastimil Babka
2018-12-14 23:02 ` [PATCH 02/14] mm, compaction: Rearrange compact_control Mel Gorman
2018-12-17 13:20 ` Vlastimil Babka
2018-12-14 23:02 ` [PATCH 03/14] mm, compaction: Remove last_migrated_pfn from compact_control Mel Gorman
2018-12-17 13:50 ` Vlastimil Babka
2018-12-14 23:03 ` [PATCH 04/14] mm, compaction: Rename map_pages to split_map_pages Mel Gorman
2018-12-17 14:06 ` Vlastimil Babka
2018-12-17 14:30 ` Mel Gorman
2018-12-14 23:03 ` [PATCH 05/14] mm, compaction: Skip pageblocks with reserved pages Mel Gorman
2018-12-18 8:08 ` Vlastimil Babka
2018-12-18 8:38 ` Mel Gorman [this message]
2018-12-14 23:03 ` [PATCH 06/14] mm, migrate: Immediately fail migration of a page with no migration handler Mel Gorman
2018-12-18 9:06 ` Vlastimil Babka
2018-12-18 9:55 ` Mel Gorman
2018-12-20 19:44 ` Yang Shi
2018-12-20 19:44 ` Yang Shi
2018-12-20 20:31 ` Mel Gorman
2018-12-14 23:03 ` [PATCH 07/14] mm, compaction: Always finish scanning of a full pageblock Mel Gorman
2018-12-18 9:23 ` Vlastimil Babka
2018-12-14 23:03 ` [PATCH 08/14] mm, compaction: Use the page allocator bulk-free helper for lists of pages Mel Gorman
2018-12-18 9:55 ` Vlastimil Babka
2018-12-19 16:04 ` Mel Gorman
2018-12-14 23:03 ` [PATCH 09/14] mm, compaction: Ignore the fragmentation avoidance boost for isolation and compaction Mel Gorman
2018-12-18 12:36 ` Vlastimil Babka
2018-12-18 13:51 ` Mel Gorman
2018-12-18 13:58 ` Vlastimil Babka
2018-12-18 14:29 ` Mel Gorman
2018-12-14 23:04 ` [PATCH 10/14] mm, compaction: Use free lists to quickly locate a migration source Mel Gorman
2018-12-14 23:05 ` [PATCH 11/14] mm, compaction: Keep migration source private to a single compaction instance Mel Gorman
2018-12-14 23:05 ` [PATCH 12/14] mm, compaction: Use free lists to quickly locate a migration target Mel Gorman
2018-12-14 23:05 ` [PATCH 13/14] mm, compaction: Capture a page under direct compaction Mel Gorman
2018-12-14 23:06 ` [PATCH 14/14] mm, compaction: Do not direct compact remote memory Mel Gorman
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=20181218083823.GI29005@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.com \
/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