linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 1/3] mm, reclaim: make should_continue_reclaim performdryrun detection
@ 2019-08-05  9:27 Hillf Danton
  2019-08-05 13:13 ` Vlastimil Babka
  0 siblings, 1 reply; 2+ messages in thread
From: Hillf Danton @ 2019-08-05  9:27 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Mike Kravetz, linux-mm, linux-kernel, Hillf Danton, Michal Hocko,
	Mel Gorman, Johannes Weiner, Andrea Arcangeli, David Rientjes,
	Andrew Morton


On Mon, 5 Aug 2019 16:43:04 +0800 Vlastimil Babka wrote:
> 
> On 8/3/19 12:39 AM, Mike Kravetz wrote:
> > From: Hillf Danton <hdanton@sina.com>
> >
> > 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 <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>
> > Tested-by: Mike Kravetz <mike.kravetz@oracle.com>
> > Acked-by: Mel Gorman <mgorman@suse.de>
> 
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
> I will send some followup cleanup.
> 
> There should be also Mike's SOB?

Yes, definitely.

Thanks
Hillf


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 1/3] mm, reclaim: make should_continue_reclaim performdryrun detection
  2019-08-05  9:27 [PATCH 1/3] mm, reclaim: make should_continue_reclaim performdryrun detection Hillf Danton
@ 2019-08-05 13:13 ` Vlastimil Babka
  0 siblings, 0 replies; 2+ messages in thread
From: Vlastimil Babka @ 2019-08-05 13:13 UTC (permalink / raw)
  To: Hillf Danton
  Cc: Mike Kravetz, linux-mm, linux-kernel, Michal Hocko, Mel Gorman,
	Johannes Weiner, Andrea Arcangeli, David Rientjes, Andrew Morton

On 8/5/19 11:27 AM, Hillf Danton wrote:

BTW, can you please do something about your mail client's lack of
In-Reply-To/References headers, which breaks threadings?

See Documentation/process/email-clients.rst:
Email clients should generate and maintain References: or In-Reply-To:
headers so that mail threading is not broken.

Thanks!


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-08-05 13:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-05  9:27 [PATCH 1/3] mm, reclaim: make should_continue_reclaim performdryrun detection Hillf Danton
2019-08-05 13:13 ` Vlastimil Babka

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).