From: Minchan Kim <minchan@kernel.org> To: David Rientjes <rientjes@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Mel Gorman <mgorman@techsingularity.net>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org> Subject: Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low Date: Tue, 18 Apr 2017 10:36:59 +0900 [thread overview] Message-ID: <20170418013659.GD21354@bbox> (raw) In-Reply-To: <alpine.DEB.2.10.1704171657550.139497@chino.kir.corp.google.com> Hello David, On Mon, Apr 17, 2017 at 05:06:20PM -0700, David Rientjes wrote: > The purpose of the code that commit 623762517e23 ("revert 'mm: vmscan: do > not swap anon pages just because free+file is low'") reintroduces is to > prefer swapping anonymous memory rather than trashing the file lru. > > If all anonymous memory is unevictable, however, this insistance on "unevictable" means hot workingset, not (mlocked and increased refcount by some driver)? I got confused. > SCAN_ANON ends up thrashing that lru instead. Sound reasonable. > > Check that enough evictable anon memory is actually on this lruvec before > insisting on SCAN_ANON. SWAP_CLUSTER_MAX is used as the threshold to > determine if only scanning anon is beneficial. Why do you use SWAP_CLUSTER_MAX instead of (high wmark + free) like file-backed pages? As considering anonymous pages have more probability to become workingset because they are are mapped, IMO, more {strong or equal} condition than file-LRU would be better to prevent anon LRU thrashing. > > Otherwise, fallback to balanced reclaim so the file lru doesn't remain > untouched. > > Signed-off-by: David Rientjes <rientjes@google.com> > --- > mm/vmscan.c | 41 +++++++++++++++++++++++------------------ > 1 file changed, 23 insertions(+), 18 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2186,26 +2186,31 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, > * anon pages. Try to detect this based on file LRU size. Please update this comment, too. > */ > if (global_reclaim(sc)) { > - unsigned long pgdatfile; > - unsigned long pgdatfree; > - int z; > - unsigned long total_high_wmark = 0; > - > - pgdatfree = sum_zone_node_page_state(pgdat->node_id, NR_FREE_PAGES); > - pgdatfile = node_page_state(pgdat, NR_ACTIVE_FILE) + > - node_page_state(pgdat, NR_INACTIVE_FILE); > - > - for (z = 0; z < MAX_NR_ZONES; z++) { > - struct zone *zone = &pgdat->node_zones[z]; > - if (!managed_zone(zone)) > - continue; > + anon = lruvec_lru_size(lruvec, LRU_ACTIVE_ANON, sc->reclaim_idx) + > + lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, sc->reclaim_idx); > + if (likely(anon >= SWAP_CLUSTER_MAX)) { With high_wmark, we can do this. if (global_reclaim(sc)) { pgdatfree = xxx; pgdatfile = xxx; total_high_wmark = xxx; if (pgdatfile + pgdatfree <= total_high_wmark) { pgdatanon = xxx; if (pgdatanon + pgdatfree > total_high_wmark) { scan_balance = SCAN_ANON; goto out; } } } > + unsigned long total_high_wmark = 0; > + unsigned long pgdatfile; > + unsigned long pgdatfree; > + int z; > + > + pgdatfree = sum_zone_node_page_state(pgdat->node_id, > + NR_FREE_PAGES); > + pgdatfile = node_page_state(pgdat, NR_ACTIVE_FILE) + > + node_page_state(pgdat, NR_INACTIVE_FILE); > + > + for (z = 0; z < MAX_NR_ZONES; z++) { > + struct zone *zone = &pgdat->node_zones[z]; > + if (!managed_zone(zone)) > + continue; > > - total_high_wmark += high_wmark_pages(zone); > - } > + total_high_wmark += high_wmark_pages(zone); > + } > > - if (unlikely(pgdatfile + pgdatfree <= total_high_wmark)) { > - scan_balance = SCAN_ANON; > - goto out; > + if (unlikely(pgdatfile + pgdatfree <= total_high_wmark)) { > + scan_balance = SCAN_ANON; > + goto out; > + } > } > } > > > -- > 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-04-18 1:37 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-18 0:06 David Rientjes 2017-04-18 1:36 ` Minchan Kim [this message] 2017-04-18 21:32 ` David Rientjes 2017-04-19 0:14 ` Minchan Kim 2017-04-19 23:24 ` David Rientjes 2017-04-20 6:09 ` Minchan Kim 2017-05-01 21:34 ` [patch v2] " David Rientjes 2017-05-02 8:02 ` Michal Hocko 2017-05-02 20:41 ` David Rientjes 2017-05-03 6:15 ` Michal Hocko 2017-05-03 7:06 ` Michal Hocko 2017-05-03 8:49 ` Michal Hocko 2017-05-03 22:52 ` David Rientjes 2017-05-04 11:43 ` Michal Hocko 2017-05-31 15:20 ` Michal Hocko 2017-06-02 20:36 ` Andrew Morton 2017-06-04 22:27 ` David Rientjes 2017-04-19 7:04 ` [patch] " Michal Hocko 2017-04-18 7:11 ` Michal Hocko
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=20170418013659.GD21354@bbox \ --to=minchan@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=rientjes@google.com \ --subject='Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low' \ /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).