From: Mike Kravetz <email@example.com> To: Vlastimil Babka <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Cc: Hillf Danton <email@example.com>, Michal Hocko <firstname.lastname@example.org>, Mel Gorman <email@example.com>, Johannes Weiner <firstname.lastname@example.org>, Andrea Arcangeli <email@example.com>, David Rientjes <firstname.lastname@example.org>, Andrew Morton <email@example.com> Subject: Re: [PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection Date: Mon, 5 Aug 2019 09:58:36 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 8/5/19 3:57 AM, Vlastimil Babka wrote: > On 8/5/19 10:42 AM, Vlastimil Babka wrote: >> On 8/3/19 12:39 AM, Mike Kravetz wrote: >>> From: Hillf Danton <firstname.lastname@example.org> >>> >>> 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. >> >> Based on Mel's longer explanation, can we clarify the wording here? e.g.: >> >> There might be side-effect for other high-order allocations that would >> potentially benefit from more reclaim before compaction for them to be >> faster and less likely to stall, but the consequences of >> premature/over-reclaim are considered worse. >> >>> 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 <email@example.com> >>> Cc: Mel Gorman <firstname.lastname@example.org> >>> Cc: Michal Hocko <email@example.com> >>> Cc: Vlastimil Babka <firstname.lastname@example.org> >>> Cc: Johannes Weiner <email@example.com> >>> Signed-off-by: Hillf Danton <firstname.lastname@example.org> >>> Tested-by: Mike Kravetz <email@example.com> >>> Acked-by: Mel Gorman <firstname.lastname@example.org> >> >> Acked-by: Vlastimil Babka <email@example.com> >> I will send some followup cleanup. > > How about this? > ----8<---- > From 0040b32462587171ad22395a56699cc036ad483f Mon Sep 17 00:00:00 2001 > From: Vlastimil Babka <firstname.lastname@example.org> > Date: Mon, 5 Aug 2019 12:49:40 +0200 > Subject: [PATCH] mm, reclaim: cleanup should_continue_reclaim() > > After commit "mm, reclaim: make should_continue_reclaim perform dryrun > detection", closer look at the function shows, that nr_reclaimed == 0 means > the function will always return false. And since non-zero nr_reclaimed implies > non_zero nr_scanned, testing nr_scanned serves no purpose, and so does the > testing for __GFP_RETRY_MAYFAIL. > > This patch thus cleans up the function to test only !nr_reclaimed upfront, and > remove the __GFP_RETRY_MAYFAIL test and nr_scanned parameter completely. > Comment is also updated, explaining that approximating "full LRU list has been > scanned" with nr_scanned == 0 didn't really work. > > Signed-off-by: Vlastimil Babka <email@example.com> Acked-by: Mike Kravetz <firstname.lastname@example.org> Would you like me to add this to the series, or do you want to send later? -- Mike Kravetz
next prev parent reply other threads:[~2019-08-05 17:01 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-02 22:39 [PATCH 0/3] address hugetlb page allocation stalls Mike Kravetz 2019-08-02 22:39 ` [PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection Mike Kravetz 2019-08-05 8:42 ` Vlastimil Babka 2019-08-05 10:57 ` Vlastimil Babka 2019-08-05 16:58 ` Mike Kravetz [this message] 2019-08-05 18:34 ` Vlastimil Babka 2019-08-05 16:54 ` Mike Kravetz 2019-08-02 22:39 ` [PATCH 2/3] mm, compaction: raise compaction priority after it withdrawns Mike Kravetz 2019-08-05 9:14 ` Vlastimil Babka 2019-08-02 22:39 ` [PATCH 3/3] hugetlbfs: don't retry when pool page allocations start to fail Mike Kravetz 2019-08-05 9:28 ` Vlastimil Babka 2019-08-05 17:12 ` 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection' \ /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
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).