From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 00/10] try to reduce fragmenting fallbacks
Date: Thu, 16 Feb 2017 16:12:27 +0100 [thread overview]
Message-ID: <ac941e43-9a5c-13fa-756e-c12c08513c9b@suse.cz> (raw)
In-Reply-To: <37f46f4c-4006-a76a-bf0a-5a4e3b0d68e6@suse.cz>
On 02/15/2017 03:29 PM, Vlastimil Babka wrote:
> On 02/13/2017 12:07 PM, Mel Gorman wrote:
>> On Fri, Feb 10, 2017 at 06:23:33PM +0100, Vlastimil Babka wrote:
>>
>> By and large, I like the series, particularly patches 7 and 8. I cannot
>> make up my mind about the RFC patches 9 and 10 yet. Conceptually they
>> seem sound but they are much more far reaching than the rest of the
>> series.
>>
>> It would be nice if patches 1-8 could be treated in isolation with data
>> on the number of extfrag events triggered, time spent in compaction and
>> the success rate. Patches 9 and 10 are tricy enough that they would need
>> data per patch where as patches 1-8 should be ok with data gathered for
>> the whole series.
>
> I've got the results with mmtests stress-highalloc modified to do
> GFP_KERNEL order-4 allocations, on 4.9 with "mm, vmscan: fix zone
> balance check in prepare_kswapd_sleep" (without that, kcompactd indeed
> wasn't woken up) on UMA machine with 4GB memory. There were 5 repeats of
> each run, as the extfrag stats are quite volatile (note the stats below
> are sums, not averages, as it was less perl hacking for me).
>
> Success rate are the same, already high due to the low order. THP and
> compaction stats also roughly the same. The extfrag stats (a bit
> modified/expanded wrt. vanilla mmtests):
>
> (the patches are stacked, and I haven't measured the non-functional-changes
> patches separately)
> base patch 2 patch 3 patch 4 patch 7 patch 8
> Page alloc extfrag event 11734984 11769620 11485185 13029676 13312786 13939417
> Extfrag fragmenting 11729231 11763921 11479301 13024101 13307281 13933978
> Extfrag fragmenting for unmovable 87848 84906 76328 78613 66025 59261
> Extfrag fragmenting unmovable placed with movable 8298 7367 5865 8479 6440 5928
> Extfrag fragmenting for reclaimable 11636074 11673657 11397642 12940253 13236444 13869509
> Extfrag fragmenting reclaimable placed with movable 389283 362396 330855 374292 390700 415478
> Extfrag fragmenting for movable 5309 5358 5331 5235 4812 5208
OK, so turns out the trace postprocessing script had mixed up movable
and reclaimable, because the tracepoint prints only the numeric value
from the enum. Commit 016c13daa5c9 ("mm, page_alloc: use masks and
shifts when converting GFP flags to migrate types") swapped movable and
reclaimable in the enum, and the script wasn't updated.
Here are the results again, after fixing the script:
base patch 2 patch 3 patch 4 patch 7 patch 8
Page alloc extfrag event 11734984 11769620 11485185 13029676 13312786 13939417
Extfrag fragmenting 11729231 11763921 11479301 13024101 13307281 13933978
Extfrag fragmenting for unmovable 87848 84906 76328 78613 66025 59261
Extfrag fragmenting unmovable placed with movable 79550 77539 70463 70134 59585 53333
Extfrag fragmenting unmovable placed with reclaim. 8298 7367 5865 8479 6440 5928
Extfrag fragmenting for reclaimable 5309 5358 5331 5235 4812 5208
Extfrag fragmenting reclaimable placed with movable 1757 1728 1703 1750 1647 1715
Extfrag fragmenting reclaimable placed with unmov. 3552 3630 3628 3485 3165 3493
Extfrag fragmenting for movable 11636074 11673657 11397642 12940253 13236444 13869509
Most of the original evaluation is still applicable, and it's nice to
see even more stronger trend of "unmovable placed with movable"
decreasing throughout the series.
The mystery of patch 4 increasing fragmenting events actually applies to
movable allocations (and not reclaimable), which is not permanent
fragmentation. But it's still significant, so I'll investigate.
It's unfortunately possible that the optimistic stats are just a result
of having more pageblocks on average marked as UNMOVABLE. That would be
fine if they were really occupied by such allocations, but not so great
otherwise. I do hope that the extra insight about existing pages coming
from Patch 4 is improving things here, not making them worse. But the
extfrag events themselves won't tell us that...
> Going in order, patch 3 might be some improvement wrt polluting
> (movable) pageblocks with unmovable, hopefully not noise.
>
> Results for patch 4 ("count movable pages when stealing from pageblock")
> are really puzzling me, as it increases the number of fragmenting events
> for reclaimable allocations, implicating "reclaimable placed with (i.e.
> falling back to) unmovable" (which is not listed separately above, but
> follows logically from "reclaimable placed with movable" not changing
> that much). I really wonder why is that. The patch effectively only
> changes the decision to change migratetype of a pageblock, it doesn't
> affect the actual stealing decision (which is always true for
> RECLAIMABLE anyway, see can_steal_fallback()). Moreover, since we can't
> distinguish UNMOVABLE from RECLAIMABLE when counting, good_pages is 0
> and thus even the decision to change pageblock migratetype shouldn't be
> changed by the patch for this case. I must recheck the implementation...
>
> Patch 7 could be cautiously labeled as improvement for reduction of
> "Fragmenting for unmovable" events, which would be perfect as that was
> the intention. For reclaimable it looks worse, but probably just within
> noise. Same goes for Patch 8, although the apparent regression for
> reclaimable looks even worse there.
>
--
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:[~2017-02-16 15:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 17:23 [PATCH v2 00/10] try to reduce fragmenting fallbacks Vlastimil Babka
2017-02-10 17:23 ` [PATCH v2 01/10] mm, compaction: reorder fields in struct compact_control Vlastimil Babka
2017-02-13 10:49 ` Mel Gorman
2017-02-14 16:33 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 02/10] mm, compaction: remove redundant watermark check in compact_finished() Vlastimil Babka
2017-02-13 10:49 ` Mel Gorman
2017-02-14 16:34 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 03/10] mm, page_alloc: split smallest stolen page in fallback Vlastimil Babka
2017-02-13 10:51 ` Mel Gorman
2017-02-13 10:54 ` Vlastimil Babka
2017-02-14 16:59 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock Vlastimil Babka
2017-02-13 10:53 ` Mel Gorman
2017-02-14 10:07 ` Xishi Qiu
2017-02-15 10:47 ` Vlastimil Babka
2017-02-15 11:56 ` Xishi Qiu
2017-02-17 16:21 ` Vlastimil Babka
2017-02-14 18:10 ` Johannes Weiner
2017-02-17 16:09 ` Vlastimil Babka
2017-02-10 17:23 ` [PATCH v2 05/10] mm, compaction: change migrate_async_suitable() to suitable_migration_source() Vlastimil Babka
2017-02-13 10:53 ` Mel Gorman
2017-02-14 18:12 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 06/10] mm, compaction: add migratetype to compact_control Vlastimil Babka
2017-02-13 10:53 ` Mel Gorman
2017-02-14 18:15 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Vlastimil Babka
2017-02-13 10:56 ` Mel Gorman
2017-02-14 20:10 ` Johannes Weiner
2017-02-17 16:32 ` Vlastimil Babka
2017-02-17 17:39 ` Johannes Weiner
2017-02-10 17:23 ` [PATCH v2 08/10] mm, compaction: finish whole pageblock to reduce fragmentation Vlastimil Babka
2017-02-13 10:57 ` Mel Gorman
2017-02-16 11:44 ` Johannes Weiner
2017-02-10 17:23 ` [RFC v2 09/10] mm, page_alloc: disallow migratetype fallback in fastpath Vlastimil Babka
2017-02-10 17:23 ` [RFC v2 10/10] mm, page_alloc: introduce MIGRATE_MIXED migratetype Vlastimil Babka
2017-03-08 2:16 ` Yisheng Xie
2017-03-08 7:07 ` Vlastimil Babka
2017-03-13 2:16 ` Yisheng Xie
2017-02-13 11:07 ` [PATCH v2 00/10] try to reduce fragmenting fallbacks Mel Gorman
2017-02-15 14:29 ` Vlastimil Babka
2017-02-15 16:11 ` Vlastimil Babka
2017-02-15 20:11 ` Vlastimil Babka
2017-02-16 15:12 ` Vlastimil Babka [this message]
2017-02-17 15:24 ` Vlastimil Babka
2017-02-20 12:30 ` Vlastimil Babka
2017-02-23 16:01 ` 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=ac941e43-9a5c-13fa-756e-c12c08513c9b@suse.cz \
--to=vbabka@suse.cz \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--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;
as well as URLs for NNTP newsgroup(s).