From: Vlastimil Babka <vbabka@suse.cz>
To: Hillf Danton <hdanton@sina.com>, Mel Gorman <mgorman@suse.de>,
Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
Date: Wed, 31 Jul 2019 13:08:44 +0200 [thread overview]
Message-ID: <295a37b1-8257-9b4a-b586-9a4990cc9d35@suse.cz> (raw)
In-Reply-To: <20190725080551.GB2708@suse.de>
On 7/26/19 9:40 AM, Hillf Danton wrote:
>
> On Thu, 25 Jul 2019 08:05:55 +0000 (UTC) Mel Gorman wrote:
>>
>> Agreed that the description could do with improvement. However, it
>> makes sense that if compaction reports it can make progress that it is
>> unnecessary to continue reclaiming.
>
> Thanks Mike and Mel.
>
> Hillf
> ---8<---
> From: Hillf Danton <hdanton@sina.com>
> Subject: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
>
> Address the issue of should_continue_reclaim continuing true too often
> for __GFP_RETRY_MAYFAIL attempts when !nr_reclaimed and nr_scanned.
> This could happen during hugetlb page allocation causing stalls for
> minutes or hours.
>
> We can stop reclaiming pages if compaction reports it can make a progress.
> A code reshuffle is needed to do that. And it has side-effects, however,
> with allocation latencies in other cases but that would come at the cost
> of potential premature reclaim which has consequences of itself.
I don't really understand that paragraph, did Mel meant it like this?
> We can also bail out of reclaiming pages if we know that there are not
> enough inactive lru pages left to satisfy the costly allocation.
>
> We can give up reclaiming pages too if we see dryrun occur, with the
> certainty of plenty of inactive pages. IOW with dryrun detected, we are
> sure we have reclaimed as many pages as we could.
>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Hillf Danton <hdanton@sina.com>
I agree this is an improvement overall, but perhaps the patch does too
many things at once. The reshuffle is one thing and makes sense. The
change of the last return condition could perhaps be separate. Also
AFAICS the ultimate result is that when nr_reclaimed == 0, the function
will now always return false. Which makes the initial test for
__GFP_RETRY_MAYFAIL and the comments there misleading. There will no
longer be a full LRU scan guaranteed - as long as the scanned LRU chunk
yields no reclaimed page, we abort.
> ---
> mm/vmscan.c | 28 +++++++++++++++-------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index f4fd02a..484b6b1 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2673,18 +2673,6 @@ static inline bool should_continue_reclaim(struct pglist_data *pgdat,
> return false;
> }
>
> - /*
> - * If we have not reclaimed enough pages for compaction and the
> - * inactive lists are large enough, continue reclaiming
> - */
> - pages_for_compaction = compact_gap(sc->order);
> - inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
> - if (get_nr_swap_pages() > 0)
> - inactive_lru_pages += node_page_state(pgdat, NR_INACTIVE_ANON);
> - if (sc->nr_reclaimed < pages_for_compaction &&
> - inactive_lru_pages > pages_for_compaction)
> - return true;
> -
> /* If compaction would go ahead or the allocation would succeed, stop */
> for (z = 0; z <= sc->reclaim_idx; z++) {
> struct zone *zone = &pgdat->node_zones[z];
> @@ -2700,7 +2688,21 @@ static inline bool should_continue_reclaim(struct pglist_data *pgdat,
> ;
> }
> }
> - return true;
> +
> + /*
> + * If we have not reclaimed enough pages for compaction and the
> + * inactive lists are large enough, continue reclaiming
> + */
> + pages_for_compaction = compact_gap(sc->order);
> + inactive_lru_pages = node_page_state(pgdat, NR_INACTIVE_FILE);
> + if (get_nr_swap_pages() > 0)
> + inactive_lru_pages += node_page_state(pgdat, NR_INACTIVE_ANON);
> +
> + return inactive_lru_pages > pages_for_compaction &&
> + /*
> + * avoid dryrun with plenty of inactive pages
> + */
> + nr_scanned && nr_reclaimed;
> }
>
> static bool pgdat_memcg_congested(pg_data_t *pgdat, struct mem_cgroup *memcg)
> --
>
WARNING: multiple messages have this Message-ID
From: Hillf Danton <hdanton@sina.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>,
Mike Kravetz <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
Date: Thu, 1 Aug 2019 11:16:33 +0800 [thread overview]
Message-ID: <295a37b1-8257-9b4a-b586-9a4990cc9d35@suse.cz> (raw)
Message-ID: <20190801031633.Y4GW2YtXQnnb-WbjqL8PxDroUmId5El6AOJE4bK5iso@z> (raw)
In-Reply-To: <20190725080551.GB2708@suse.de>
On Wed, 31 Jul 2019 13:08:44 +0200 Vlastimil Babka wrote:
>
> I agree this is an improvement overall, but perhaps the patch does too
> many things at once. The reshuffle is one thing and makes sense. The
> change of the last return condition could perhaps be separate. Also
> AFAICS the ultimate result is that when nr_reclaimed == 0, the function
> will now always return false. Which makes the initial test for
> __GFP_RETRY_MAYFAIL and the comments there misleading. There will no
> longer be a full LRU scan guaranteed - as long as the scanned LRU chunk
> yields no reclaimed page, we abort.
>
Thanks Vlastimil.
We can drop the test for __GFP_RETRY_MAYFAIL imo after observing no
regression produced by the reshuffle combined with dryrun detection
for reasons that
1) such a full lru scan is too expensive a cost for kswapd to pay for
balancing a node. The kthread you see drops the costly order when
appropriate. Which makes the helper in question false.
2) it has been a while otoh that reclaimers play game with neither
the costly order nor __GFP_RETRY_MAYFAIL taken into account, see
commit 2bb0f34fe3c1 ("mm: vmscan: do not iterate all mem cgroups for
global direct reclaim") for instance.
Hillf
next prev parent reply other threads:[~2019-07-31 11:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 17:50 [RFC PATCH 0/3] fix hugetlb page allocation stalls Mike Kravetz
2019-07-24 17:50 ` [RFC PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection Mike Kravetz
2019-07-25 8:05 ` Mel Gorman
2019-07-26 7:40 ` Hillf Danton
2019-07-26 8:12 ` Mel Gorman
2019-07-31 11:08 ` Vlastimil Babka [this message]
2019-07-31 12:25 ` Mel Gorman
2019-07-31 21:11 ` Mike Kravetz
2019-08-01 4:22 ` Hillf Danton
2019-08-01 8:44 ` Vlastimil Babka
2019-08-01 3:16 ` Hillf Danton
2019-07-24 17:50 ` [RFC PATCH 2/3] mm, compaction: use MIN_COMPACT_COSTLY_PRIORITY everywhere for costly orders Mike Kravetz
2019-07-25 8:06 ` Mel Gorman
2019-07-31 12:06 ` Vlastimil Babka
2019-07-31 20:30 ` Mike Kravetz
2019-08-01 13:01 ` Vlastimil Babka
2019-08-01 20:33 ` Mike Kravetz
2019-08-02 10:20 ` Vlastimil Babka
2019-08-02 12:05 ` Vlastimil Babka
2019-08-02 17:44 ` Mike Kravetz
2019-07-24 17:50 ` [RFC PATCH 3/3] hugetlbfs: don't retry when pool page allocations start to fail Mike Kravetz
2019-07-25 8:13 ` Mel Gorman
2019-07-25 17:15 ` Mike Kravetz
2019-07-25 22:43 ` Mel Gorman
2019-07-31 13:23 ` Vlastimil Babka
2019-07-31 21:13 ` Mike Kravetz
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=295a37b1-8257-9b4a-b586-9a4990cc9d35@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.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