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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 B2603C433E0 for ; Thu, 11 Mar 2021 00:58:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2292F64FA1 for ; Thu, 11 Mar 2021 00:58:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2292F64FA1 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 972348D025B; Wed, 10 Mar 2021 19:58:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9238D8D0250; Wed, 10 Mar 2021 19:58:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C58D8D025B; Wed, 10 Mar 2021 19:58:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 622B48D0250 for ; Wed, 10 Mar 2021 19:58:03 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1C6C52C8F for ; Thu, 11 Mar 2021 00:58:03 +0000 (UTC) X-FDA: 77905781646.17.5DDAF91 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf21.hostedemail.com (Postfix) with ESMTP id DA66AE000108 for ; Thu, 11 Mar 2021 00:58:00 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id u4so36899125lfs.0 for ; Wed, 10 Mar 2021 16:58:02 -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=CrfiISBeWcM0aghiGCmSAIV9dxcofoH89E4I2n3l8ko=; b=fOC/xkbof84GSdDqGTqMuAYyiGl9AT6rEWRfjjF30HZBilUqm25UMz9Zh8pezHE+lY VrwLXmP2U2XJl0HYbYqDhCd5fZ1oImvNq3Uz259jpqJqG0sNu6Yr/EMbuhSJTMM9nRKo euin/u8aCf9vResvfQ5bxbg5AVU4TpRd1zmSok1+VFvnE1LeQKELyQ1cJtxjR4KKwKgm bSuSsrm1kh9KROHeh4624u58UIG8aXB27Z4Fp/xDPfcCAvlb4c9XPNnRlz3zbk0gXZi1 mpCjKqw//YoPe2Khl+6Qx7ux47X7Eg47OQuDQss9gnQc55vAUhKdytduEXUN2s8bdYkp U2nQ== 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=CrfiISBeWcM0aghiGCmSAIV9dxcofoH89E4I2n3l8ko=; b=N3v2kF/OKoUNzdJh2HPWcePjfScvphgXXxwURGmptylYMmUCf+NovELPq4hsl/ylJp z3Xl1ELLGN14oeHZ/cz0sFbyNKYrmpW2oZquS5f5ziOphchBPmicOoCd3NKmfJ7lTEN6 8+ke4QVlSUwHmhw/Y6MjyCxvvpzXY8OVqlkz/T72C2kZgRSS1CzjdLQfOAg63Zon+g4C jvPE8FZ3hoIRN6AfNocTUv5sIBBtXR1LUH1olhcyHQ3DPUiQCz9jQwX8ewmh24l0DbvS +tsdprX6A9XVHLh9zS2RMwhXUDeNgRZWxcmCW/GRIILRLMhxglO0OY9XGCW6wO6imSkE +njw== X-Gm-Message-State: AOAM532cxe/9az4edYk6PaQNx0QcJxL3xM/tnsF9+EpoJGJul5JoPOk/ YcTzDmCo6GsvGhYpySPLKQXnhlIUkCNU83wWORjHOA== X-Google-Smtp-Source: ABdhPJwMGRKq9/WgW0SNx8+uw2SlrViPc03sBFHB9sWqOYawhu2bCVGCKfQ+zEg9JyrhTauiMKXGeqYxoahn9yitUZo= X-Received: by 2002:a19:3804:: with SMTP id f4mr721936lfa.117.1615424280844; Wed, 10 Mar 2021 16:58:00 -0800 (PST) MIME-Version: 1.0 References: <20210311004449.1170308-1-ying.huang@intel.com> In-Reply-To: <20210311004449.1170308-1-ying.huang@intel.com> From: Shakeel Butt Date: Wed, 10 Mar 2021 16:57:49 -0800 Message-ID: Subject: Re: [PATCH] vmscan: retry without cache trim mode if nothing scanned To: "Huang, Ying" , Tejun Heo Cc: Andrew Morton , Linux MM , LKML , Mel Gorman , Johannes Weiner , Vladimir Davydov , Michal Hocko , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: xryapwomkd9mb3emzjdmmp6gamj915yz X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: DA66AE000108 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mail-lf1-f48.google.com; client-ip=209.85.167.48 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615424280-865400 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 Wed, Mar 10, 2021 at 4:47 PM Huang, Ying wrote: > > From: Huang Ying > > In shrink_node(), to determine whether to enable cache trim mode, the > LRU size is gotten via lruvec_page_state(). That gets the value from > a per-CPU counter (mem_cgroup_per_node->lruvec_stat[]). The error of > the per-CPU counter from CPU local counting and the descendant memory > cgroups may cause some issues. We run into this in 0-Day performance > test. > > 0-Day uses the RAM file system as root file system, so the number of > the reclaimable file pages is very small. In the swap testing, the > inactive file LRU list will become almost empty soon. But the size of > the inactive file LRU list gotten from the per-CPU counter may keep a > much larger value (say, 33, 50, etc.). This will enable cache trim > mode, but nothing can be scanned in fact. The following pattern > repeats for long time in the test, > > priority inactive_file_size cache_trim_mode > 12 33 0 > 11 33 0 > ... > 6 33 0 > 5 33 1 > ... > 1 33 1 > > That is, the cache_trim_mode will be enabled wrongly when the scan > priority decreases to 5. And the problem will not be recovered for > long time. > > It's hard to get the more accurate size of the inactive file list > without much more overhead. And it's hard to estimate the error of > the per-CPU counter too, because there may be many descendant memory > cgroups. But after the actual scanning, if nothing can be scanned > with the cache trim mode, it should be wrong to enable the cache trim > mode. So we can retry with the cache trim mode disabled. This patch > implement this policy. Instead of playing with the already complicated heuristics, we should improve the accuracy of the lruvec stats. Johannes already fixed the memcg stats using rstat infrastructure and Tejun has suggestions on how to use rstat infrastructure efficiently for lruvec stats at https://lore.kernel.org/linux-mm/YCFgr300eRiEZwpL@slm.duckdns.org/.