From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751542AbdEBIDN (ORCPT ); Tue, 2 May 2017 04:03:13 -0400 Received: from mx2.suse.de ([195.135.220.15]:55026 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750892AbdEBICu (ORCPT ); Tue, 2 May 2017 04:02:50 -0400 Date: Tue, 2 May 2017 10:02:47 +0200 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Minchan Kim , Johannes Weiner , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch v2] mm, vmscan: avoid thrashing anon lru when free + file is low Message-ID: <20170502080246.GD14593@dhcp22.suse.cz> References: <20170418013659.GD21354@bbox> <20170419001405.GA13364@bbox> <20170420060904.GA3720@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 01-05-17 14:34:21, David Rientjes wrote: [...] > @@ -2204,8 +2204,17 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg, > } > > if (unlikely(pgdatfile + pgdatfree <= total_high_wmark)) { > - scan_balance = SCAN_ANON; > - goto out; > + /* > + * Force SCAN_ANON if there are enough inactive > + * anonymous pages on the LRU in eligible zones. > + * Otherwise, the small LRU gets thrashed. > + */ > + if (!inactive_list_is_low(lruvec, false, sc, false) && > + lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, sc->reclaim_idx) > + >> sc->priority) { > + scan_balance = SCAN_ANON; > + goto out; > + } I have already asked and my questions were ignored. So let me ask again and hopefuly not get ignored this time. So Why do we need a different criterion on anon pages than file pages? I do agree that blindly scanning anon pages when file pages are low is very suboptimal but this adds yet another heuristic without _any_ numbers. Why cannot we simply treat anon and file pages equally? Something like the following if (pgdatfile + pgdatanon + pgdatfree > 2*total_high_wmark) { scan_balance = SCAN_FILE; if (pgdatfile < pgdatanon) scan_balance = SCAN_ANON; goto out; } Also it would help to describe the workload which can trigger this behavior so that we can compare numbers before and after this patch. -- Michal Hocko SUSE Labs