From: Vlastimil Babka <vbabka@suse.cz>
To: David Rientjes <rientjes@google.com>, Joonsoo Kim <js1304@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Aaron Lu <aaron.lu@intel.com>, Mel Gorman <mgorman@suse.de>,
Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous
Date: Wed, 23 Dec 2015 07:14:21 +0100 [thread overview]
Message-ID: <567A3BBD.80408@suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1512221410380.5172@chino.kir.corp.google.com>
On 22.12.2015 23:17, David Rientjes wrote:
> On Mon, 21 Dec 2015, Joonsoo Kim wrote:
>
>> Before vs After
>> Max: 1096 MB/s vs 1325 MB/s
>> Min: 635 MB/s 1015 MB/s
>> Avg: 899 MB/s 1194 MB/s
>>
>> Avg is improved by roughly 30% [2].
>>
>
> Wow, ok!
>
> I'm wondering if it would be better to maintain this as a characteristic
> of each pageblock rather than each zone. Have you tried to introduce a
> couple new bits to pageblock_bits that would track (1) if a cached value
> makes sense and (2) if the pageblock is contiguous? On the first call to
> pageblock_pfn_to_page(), set the first bit, PB_cached, and set the second
> bit, PB_contiguous, iff it is contiguous. On subsequent calls, if
> PB_cached is true, then return PB_contiguous. On memory hot-add or
> remove (or init), clear PB_cached.
I can imagine these bitmap operation to be as expensive as what
__pageblock_pfn_to_page() does (or close)? But if not, we could also just be a
bit smarter about PG_skip and check that before doing pfn_to_page.
> What are the cases where pageblock_pfn_to_page() is used for a subset of
> the pageblock and the result would be problematic for compaction? I.e.,
> do we actually care to use pageblocks that are not contiguous at all?
The problematic pageblocks are those that have pages from more than one zone in
them, so we just skip them. Supposedly that can only happen by switching once
between two zones somewhere in the middle of the pageblock, so it's sufficient
to check first and last pfn and compare their zones. So using
pageblock_pfn_to_page() on a subset from compaction would be wrong. Holes (==no
pages) within pageblock is a different thing checked by pfn_valid_within()
(#defined out on archs where such holes cannot happen) when scanning the block.
That's why I'm not entirely happy with how the patch conflates both the
first/last pfn's zone checks and pfn_valid_within() checks. Yes, a fully
contiguous zone does *imply* that pageblock_pfn_to_page() doesn't have to check
first/last pfn for a matching zone. But it's not *equality*. And any (now just
*potential*) user of pageblock_pfn_to_page() with pfn's different than
first/last pfn of a pageblock is likely wrong.
--
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-12-23 6:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 6:13 [PATCH 1/2] mm/compaction: fix invalid free_pfn and compact_cached_free_pfn Joonsoo Kim
2015-12-21 6:13 ` [PATCH 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous Joonsoo Kim
2015-12-21 10:46 ` Vlastimil Babka
2015-12-21 12:18 ` Joonsoo Kim
2015-12-21 12:38 ` Joonsoo Kim
2015-12-22 22:17 ` David Rientjes
2015-12-23 6:14 ` Vlastimil Babka [this message]
2015-12-23 6:57 ` Joonsoo Kim
2016-01-04 12:38 ` Vlastimil Babka
2016-01-08 2:52 ` Joonsoo Kim
2016-01-19 8:29 ` zhong jiang
2015-12-22 22:05 ` [PATCH 1/2] mm/compaction: fix invalid free_pfn and compact_cached_free_pfn David Rientjes
-- strict thread matches above, loose matches on Subject: below --
2015-12-14 5:02 Joonsoo Kim
2015-12-14 5:02 ` [PATCH 2/2] mm/compaction: speed up pageblock_pfn_to_page() when zone is contiguous Joonsoo Kim
2015-12-14 10:29 ` Vlastimil Babka
2015-12-14 15:25 ` Joonsoo Kim
2015-12-15 1:06 ` Aaron Lu
2015-12-15 8:24 ` Vlastimil Babka
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=567A3BBD.80408@suse.cz \
--to=vbabka@suse.cz \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--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=riel@redhat.com \
--cc=rientjes@google.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