From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75E54FC6194 for ; Thu, 7 Nov 2019 02:52:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2705F217F5 for ; Thu, 7 Nov 2019 02:52:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hrYAJcfj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2705F217F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D0C3D6B0008; Wed, 6 Nov 2019 21:52:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C95B36B000A; Wed, 6 Nov 2019 21:52:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B85D06B000D; Wed, 6 Nov 2019 21:52:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id A0A596B0008 for ; Wed, 6 Nov 2019 21:52:37 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 5C7C54408 for ; Thu, 7 Nov 2019 02:52:37 +0000 (UTC) X-FDA: 76127958354.13.spade96_16d78a7dfa24c X-HE-Tag: spade96_16d78a7dfa24c X-Filterd-Recvd-Size: 8687 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 02:52:36 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id n14so618443oie.13 for ; Wed, 06 Nov 2019 18:52:36 -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=LKlERTl9DvESYF3m/JsPRK2Ra4f773JCe1klUlJdfm8=; b=hrYAJcfjB5EUPkKmDUrpuOx0lOQSIA3j08ysAaXeXLKb013qoG8F1U6i/uTp1u8D/j fqryyYhwNLlzpm+LXUPaswVejzLsCS+peFQOt/ppVHTmoWcZUa8qdu2HWkt9U0X6Ey73 bUtJkqxyxnUdRj/m0t9D9khHaLSUXvAIoSrMmDg8DvTCTz6lsQVTFuRkNIeo1fX+sRiL cqrTz/Stsei5t2BjQwO4UxGaex6ar7Q1ucu7SJGWY3q+jUemNmuN7rCnaXM1QJugbHl3 n0v+r+JzONbo2agmPVu+BpZpJiFWgEBy83Yb554Rkq/4yqOlT0krKIeXL5ohHFTBnhbJ 0NQQ== 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=LKlERTl9DvESYF3m/JsPRK2Ra4f773JCe1klUlJdfm8=; b=ciaipM4Agf6wZmHAoAGMbNtzDWp85H41U8N6Z26+htrWr4QiAFJqDHMRf/hazbfQAL by9jSu6BGFvJowNhWqrpBpmmVvwy8A3hQixiZtzR9wegyqoe90vmW9P6Gih58JsvxDsb Cg9J8T0pF1JNl7S7X1exWVc3dry1ke+PYGsQh60WHy3QnWwOqs9v79wob0MEXclXYeXE aWmRod040aFDPHoAzKEzrVxmTekdd69pUhXXIeuBphLXVub/ir8M52AIVVAuq8ROkOFL hswz0VCc0zacO0iXni0YpHRGM0lqb6Vj7Ed2iUeC8NJheuEag8PAy27qwm9V6NY1S7ak THcQ== X-Gm-Message-State: APjAAAW1+BrQ9LciEWDx73//xOLymcWZPoWy5xiIc3TdofQNNx9x8ba/ XAguc4sn/7lzZbd1OCNiOXKDxgOjdPr25KliOByWnA== X-Google-Smtp-Source: APXvYqxLSyryF3fKienTgCOzEZBGe6VVLooYyUdjdZWIh5gWqNJaOwiIFMEpUA637TIkM9C7K86t7b/a/gCOhlrRXzw= X-Received: by 2002:aca:4fce:: with SMTP id d197mr1237938oib.142.1573095155625; Wed, 06 Nov 2019 18:52:35 -0800 (PST) MIME-Version: 1.0 References: <20190603210746.15800-1-hannes@cmpxchg.org> <20190603210746.15800-10-hannes@cmpxchg.org> In-Reply-To: <20190603210746.15800-10-hannes@cmpxchg.org> From: Shakeel Butt Date: Wed, 6 Nov 2019 18:52:23 -0800 Message-ID: Subject: Re: [PATCH 09/11] mm: vmscan: move file exhaustion detection to the node level To: Johannes Weiner Cc: Andrew Morton , Andrey Ryabinin , Suren Baghdasaryan , Michal Hocko , Linux MM , Cgroups , LKML , Kernel Team Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jun 3, 2019 at 3:08 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 > 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 eb535c572733..cabf94dfa92d 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -104,6 +104,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; > > @@ -2219,45 +2222,16 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, > } > Unrelated to the patch. I think we need to revisit all the heuristics that were added here over the years. get_scan_count() has become really complicated and weird. > /* > - * 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; > } > > /* > @@ -2718,6 +2692,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.21.0 >