From: Michal Hocko <firstname.lastname@example.org> To: David Rientjes <email@example.com> Cc: Minchan Kim <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Johannes Weiner <firstname.lastname@example.org>, Mel Gorman <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: [patch] mm, vmscan: avoid thrashing anon lru when free + file is low Date: Wed, 19 Apr 2017 09:04:25 +0200 [thread overview] Message-ID: <20170419070424.GA28263@dhcp22.suse.cz> (raw) In-Reply-To: <alpine.DEB.firstname.lastname@example.org> On Tue 18-04-17 14:32:56, David Rientjes wrote: [...] > If the suggestion is checking > NR_ACTIVE_ANON + NR_INACTIVE_ANON > total_high_wmark pages, it would be a > separate heurstic to address a problem that I'm not having :) My issue is > specifically when NR_ACTIVE_FILE + NR_INACTIVE_FILE < total_high_wmark, > NR_ACTIVE_ANON + NR_INACTIVE_ANON is very large, but all not on this > lruvec's evictable lrus. Hmm, why are those pages not moved to the unevictable LRU lists? > This is the reason why I chose lruvec_lru_size() rather than per-node > statistics. The argument could also be made for the file lrus in the > get_scan_count() heuristic that forces SCAN_ANON, but I have not met such > an issue (yet). I could follow-up with that change or incorporate it into > a v2 of this patch if you'd prefer. > > In other words, I want get_scan_count() to not force SCAN_ANON and > fallback to SCAN_FRACT, absent other heuristics, if the amount of > evictable anon is below a certain threshold for this lruvec. I > arbitrarily chose SWAP_CLUSTER_MAX to be conservative, but I could easily > compare to total_high_wmark as well, although I would consider that more > aggressive. > > So we're in global reclaim, our file lrus are below thresholds, but we > don't want to force SCAN_ANON for all lruvecs if there's not enough to > reclaim from evictable anon. Do you have a suggestion for how to > implement this logic other than this patch? I agree that forcing SCAN_ANON without looking at the ANON lru size is not optimal but I would rather see the same criterion for both anon and file. get_scan_count is full of magic heuristics which tend to break for different workloads. Let's not add another magic on top please. -- Michal Hocko SUSE Labs
next prev parent reply other threads:[~2017-04-19 7:04 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 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 ` Michal Hocko [this message] 2017-04-18 7:11 ` [patch] " 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=20170419070424.GA28263@dhcp22.suse.cz \ --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] 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).