Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp5468309ybx; Sun, 10 Nov 2019 14:05:36 -0800 (PST) X-Google-Smtp-Source: APXvYqwQXf2pyvXv+mweRnjt5LIDbSGp6dQJq1yzuQxI/cqajMjQ8B1X1hRgGYhLXZlBjX9CbcQx X-Received: by 2002:a05:6402:1543:: with SMTP id p3mr1092322edx.304.1573423536549; Sun, 10 Nov 2019 14:05:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573423536; cv=none; d=google.com; s=arc-20160816; b=yUJlEulXV34Iq8jiAqZVW/8zS2wkTnp+ChWqz4RP0CkYHw1Zk1xcKebNFg9s/L76Hv M7FInT2l0i9IIKrsHI78Y/g/JLaO+MyUK4mydvtShSrvWp64z953VRtLLxX6fm6vzCZh LjPmeItUKcGcodM7PPSF7XrRu7qeeUuO6IyKulTGLPulrv+IssoTuBr7BLiOQuOjRg77 aSgaKkQC5j1W9RxSMZrPI9HShxHZje5j1HsiX6W1GpxWK+hgWlkhukSKq3v6T2EqwrzQ uLEwGhk1p32JzZwxAIoRC37amQ5DiBf80cV2VTP4A8EvbISsdlQNHSzZHKgNYmM+Tl/S wXvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=XiZ3YYvjZNzRtqsEDX9KtMzE3FSNUK/E0+y+ayqaNl8=; b=JNGOYR6cO1brI+qlMUu4pTSXpxkCbHAvDv3wbGtkvqmvMx1WF2PVu/tvGWekjeZ6Ev a1lKWaWyFSP4GsszMUnhBKhwUh5lse3u5wMfBpyD78bZKD0tlMkjbYVr6UQBJorB6T9n 5fkE/JTTTsi15QGOqb42R88pehz2yoz/RqB8YrOUN3q+3gELelhBNuXtWXMUaZePNrHd R0mmY/IYIJyOzkV/9BMkFpkZDhBmSrfPZjZbdxCWnsrtByF+u9Cz/9v5erSmUI6cAW8w VXBSACA2ju8ipaG9PKJSjnR4EgTsZMFCexiyfEcbCwkADKEDeIsgsIRWVPX8C8REKEuX tVNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WtlaAoKE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si8907899edq.394.2019.11.10.14.05.13; Sun, 10 Nov 2019 14:05:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WtlaAoKE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727211AbfKJWCc (ORCPT + 99 others); Sun, 10 Nov 2019 17:02:32 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:43641 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726973AbfKJWCb (ORCPT ); Sun, 10 Nov 2019 17:02:31 -0500 Received: by mail-wr1-f65.google.com with SMTP id n1so12525089wra.10 for ; Sun, 10 Nov 2019 14:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XiZ3YYvjZNzRtqsEDX9KtMzE3FSNUK/E0+y+ayqaNl8=; b=WtlaAoKErXP6oWh9i1Y6e6ZRKTHN70XjeRLT416hN1ckMpqtDzYCh+sR89mKX21gf/ UDGPs7klFvQmfC2EAAEFjL5vS/p3ehYtYldNJeRbr/WD6n5UDaIfuAsJ84tzUJXOVNnW G3Abu0CUUlai+X19pH9le4z/OxWuKC8BmsSPo0G7gupdv5mRhUPE+X1bM2dOfcbu3Ws7 QNytQroxH332qqmKc4uwHRCLX/hsRbWdu5DGiuagbPOTsYRrgKAipm2I72VJeTp3jlsE z4fjNZQrUd2PeXyAnKiCGzcAOeoYJynZd+8WoCvCk8xMv2Lxy5hFQakBkCZbSrZ1L0BV ypfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XiZ3YYvjZNzRtqsEDX9KtMzE3FSNUK/E0+y+ayqaNl8=; b=e28+QQT3a9wxBmXZAZQSqJMnzvGoa2NXXncP716mWojXkdV1V+O2VWGkgrSSJ9Vy3y JmzNNQZVDmFbGx7ATgzB7oPupEyq8RwQJ0bLnPo0W9hYZjROMwjErUS7a1Xup4J7M0m8 /PG097asjNXs2sCQmdOyoz6TQZdsCxD0+ckRBEM/11Q8iSAFeR4AkL/SPvR1EWmFlm8Q scYCi6DDW9zf3GujDISS74dXpcumxJd2vCYJIgqIIsfK8ZMcz+mlCfllKTNPaPmb2+oQ nBx7se/LbglkWPWBQujZPx786BTXdzvMfRLhp0VyLDjDs4ScdBMO8vHbI0kLBNSmIB3I an3g== X-Gm-Message-State: APjAAAW5vDTtrdD2tU3RNRM4s4YJddfXgd815rfcC6Q8io+vD4lNZGtW lUuvvQaifaGzyjwpwqyC4/dmX5vUTla1C/Suq3sAmA== X-Received: by 2002:a5d:678c:: with SMTP id v12mr6403180wru.116.1573423348179; Sun, 10 Nov 2019 14:02:28 -0800 (PST) MIME-Version: 1.0 References: <20191107205334.158354-1-hannes@cmpxchg.org> <20191107205334.158354-2-hannes@cmpxchg.org> In-Reply-To: <20191107205334.158354-2-hannes@cmpxchg.org> From: Suren Baghdasaryan Date: Sun, 10 Nov 2019 14:02:17 -0800 Message-ID: Subject: Re: [PATCH 1/3] mm: vmscan: move file exhaustion detection to the node level To: Johannes Weiner Cc: Andrew Morton , Andrey Ryabinin , Shakeel Butt , Rik van Riel , Michal Hocko , linux-mm , cgroups mailinglist , LKML , kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 7, 2019 at 12:53 PM Johannes Weiner wrote: > > When file pages are lower than the watermark on a node, we try to > force scan anonymous pages to counter-act the balancing algorithms > preference for new file pages when they are likely thrashing. This is > a node-level decision, but it's currently made each time we look at an > lruvec. This is unnecessarily expensive and also a layering violation > that makes the code harder to understand. > > Clean this up by making the check once per node and setting a flag in > the scan_control. > > Signed-off-by: Johannes Weiner > Reviewed-by: Shakeel Butt > --- > mm/vmscan.c | 80 ++++++++++++++++++++++++++++------------------------- > 1 file changed, 42 insertions(+), 38 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d97985262dda..e8dd601e1fad 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -101,6 +101,9 @@ struct scan_control { > /* One of the zones is ready for compaction */ > unsigned int compaction_ready:1; > > + /* The file pages on the current node are dangerously low */ > + unsigned int file_is_tiny:1; > + > /* Allocation order */ > s8 order; > > @@ -2289,45 +2292,16 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > } > > /* > - * Prevent the reclaimer from falling into the cache trap: as > - * cache pages start out inactive, every cache fault will tip > - * the scan balance towards the file LRU. And as the file LRU > - * shrinks, so does the window for rotation from references. > - * This means we have a runaway feedback loop where a tiny > - * thrashing file LRU becomes infinitely more attractive than > - * anon pages. Try to detect this based on file LRU size. > + * If the system is almost out of file pages, force-scan anon. > + * But only if there are enough inactive anonymous pages on > + * the LRU. Otherwise, the small LRU gets thrashed. > */ > - if (!cgroup_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; > - > - total_high_wmark += high_wmark_pages(zone); > - } > - > - if (unlikely(pgdatfile + pgdatfree <= total_high_wmark)) { > - /* > - * 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; > - } > - } > + if (sc->file_is_tiny && > + !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; > } > > /* > @@ -2754,6 +2728,36 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc) > nr_reclaimed = sc->nr_reclaimed; > nr_scanned = sc->nr_scanned; > > + /* > + * Prevent the reclaimer from falling into the cache trap: as > + * cache pages start out inactive, every cache fault will tip > + * the scan balance towards the file LRU. And as the file LRU > + * shrinks, so does the window for rotation from references. > + * This means we have a runaway feedback loop where a tiny > + * thrashing file LRU becomes infinitely more attractive than > + * anon pages. Try to detect this based on file LRU size. > + */ > + if (!cgroup_reclaim(sc)) { > + unsigned long file; > + unsigned long free; > + int z; > + unsigned long total_high_wmark = 0; > + > + free = sum_zone_node_page_state(pgdat->node_id, NR_FREE_PAGES); > + file = 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); > + } > + > + sc->file_is_tiny = file + free <= total_high_wmark; > + } > + > shrink_node_memcgs(pgdat, sc); > > if (reclaim_state) { > -- > 2.24.0 > Hi Johannes, Thanks for working on this! On Android reclaim regression caused by memcgs is a known issue and I'll try to test your patcheset next week. Reviewed-by: Suren Baghdasaryan