From: Mel Gorman <mgorman@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: linux-mm@kvack.org, mhocko@suse.cz
Subject: Re: [PATCH 1/6] mm: migration: Factor out code to compute expected number of page references
Date: Fri, 14 Dec 2018 16:24:28 +0000 [thread overview]
Message-ID: <20181214162428.GH28934@suse.de> (raw)
In-Reply-To: <20181214155311.GG8896@quack2.suse.cz>
On Fri, Dec 14, 2018 at 04:53:11PM +0100, Jan Kara wrote:
> > I noticed during testing that THP allocation success rates under the
> > mmtests configuration global-dhp__workload_thpscale-madvhugepage-xfs were
> > terrible with massive latencies introduced somewhere in the series. I
> > haven't tried chasing it down as it's relatively late but this block
> > looked odd and I missed it the first time.
>
> Interesting. I've run config-global-dhp__workload_thpscale and that didn't
> show anything strange. But the numbers were fluctuating a lot both with and
> without my patches applied. I'll have a look if I can reproduce this
> sometime next week and look what could be causing the delays.
>
Ah, it's the difference between madvise and !madvise. The configuration
you used does very little compaction as it neither wakes kswapd of
kcompactd. It just falls back to base pages to limit fault latency so
you wouldn't have hit the same paths of interest.
> > This page->mapping test is relevant for the "Anonymous page without
> > mapping" check but I think it's wrong. An anonymous page without mapping
> > doesn't have a NULL mapping, it sets PAGE_MAPPING_ANON and the field can
> > be special in other ways. I think you meant to use page_mapping(page)
> > here, not page->mapping?
>
> Yes, that's a bug. It should have been page_mapping(page). Thanks for
> catching this.
>
My pleasure, should have spotted it the first time around :/
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2018-12-14 16:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 17:21 mm: migrate: Fix page migration stalls for blkdev pages Jan Kara
2018-12-11 17:21 ` [PATCH 1/6] mm: migration: Factor out code to compute expected number of page references Jan Kara
2018-12-13 13:05 ` Mel Gorman
2018-12-14 15:10 ` Mel Gorman
2018-12-14 15:53 ` Jan Kara
2018-12-14 16:24 ` Mel Gorman [this message]
2018-12-17 13:11 ` Jan Kara
2018-12-11 17:21 ` [PATCH 2/6] mm: migrate: Lock buffers before migrate_page_move_mapping() Jan Kara
2018-12-13 14:19 ` Mel Gorman
2018-12-11 17:21 ` [PATCH 3/6] mm: migrate: Move migrate_page_lock_buffers() Jan Kara
2018-12-13 14:57 ` Mel Gorman
2018-12-11 17:21 ` [PATCH 4/6] mm: migrate: Provide buffer_migrate_page_norefs() Jan Kara
2018-12-13 15:34 ` Mel Gorman
2018-12-14 4:53 ` Andrew Morton
2018-12-14 9:26 ` Jan Kara
2018-12-11 17:21 ` [PATCH 5/6] blkdev: Avoid migration stalls for blkdev pages Jan Kara
2018-12-13 15:35 ` Mel Gorman
2018-12-11 17:21 ` [PATCH 6/6] mm: migrate: Drop unused argument of migrate_page_move_mapping() Jan Kara
2018-12-13 15:35 ` Mel Gorman
2018-12-13 16:17 ` Jan Kara
2018-12-17 13:17 ` Jan Kara
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=20181214162428.GH28934@suse.de \
--to=mgorman@suse.de \
--cc=jack@suse.cz \
--cc=linux-mm@kvack.org \
--cc=mhocko@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 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).