Message ID | 20230228085002.2592473-3-yosryahmed@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2907314wrd; Tue, 28 Feb 2023 01:19:39 -0800 (PST) X-Google-Smtp-Source: AK7set9n1+wvEwYNR/irTlg7K5tjejFAi9/m6PJJN1tECw8LnOft1fTybisy57d0rbdqFpxoGoat X-Received: by 2002:a17:902:d504:b0:19c:e842:a9e0 with SMTP id b4-20020a170902d50400b0019ce842a9e0mr2157907plg.16.1677575978822; Tue, 28 Feb 2023 01:19:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677575978; cv=none; d=google.com; s=arc-20160816; b=vldkHPQqiidJFyg10AEDgro8PvxsMfFD3gJA3wWR9MsgC02eAwxU3vY4r2ozmVb95h uDNWt5MVvNIj5ltHFJUbfozrKarQXlq/tEMd0bxAaSZ4Q/HmHvcrGiKlWs+ALo5qtgbp zuoMYo7FhQNbZJ8nhb6g3puGO7e9NdV6QdnKJptYIVAeiBe71wSDoYdfEpgrweQ3QPO3 t6NRr+UR46M2PWijjiSyHTBm10N1VRhgNV4+T0+ypbDIhGR5frxbCrTFQk+mC/DXYRty Hw+z9XVLnbh2B/6QwkC1TPSe9xwKtWFtGPntOKf59awVBhBIdGIyRKf4IPLd4ztiVbey LIfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=th38ntbA4Oc2oiVVTEFN7kVCZXMfBHW5bqzoJX/NKxM=; b=ZxdtCxfVElFUnuAMZXY5W71aCLk3vIDlQuPxB0oOOqCbJAvOzOq1Sj0edFfV/VRyqy QS+/oFJhk5FnyT+XPQJNuKiGpDz7YifruqwX9le8o7j01p7mkvSZSiHPALtwHmmMYBnC LhwUjpD6c6BcvcoXXa9UZ5RpEn1LxrFy/lPbKH6nGD07YyZY8OL95m7MDzK0ubUZukGg 6TQCkw/TspMYWMvVeCvApcfd+/908muVKL/ScEijGSJAMqPThoMyNKywJGqzNGCEvELr zeM6JHkh7ddII5A7tQEkzXdkPdwXv+KHelKQsEThY3q7rWOMt4X5izOjOY78JoX3CH/v ANdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Qx1HMjnO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jh5-20020a170903328500b0019ad3a672d8si9226386plb.83.2023.02.28.01.19.25; Tue, 28 Feb 2023 01:19:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Qx1HMjnO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S230315AbjB1IuZ (ORCPT <rfc822;brysonjbanks@gmail.com> + 99 others); Tue, 28 Feb 2023 03:50:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230341AbjB1IuS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Feb 2023 03:50:18 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87FF11A97E for <linux-kernel@vger.kernel.org>; Tue, 28 Feb 2023 00:50:10 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-536d63d17dbso199086627b3.22 for <linux-kernel@vger.kernel.org>; Tue, 28 Feb 2023 00:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677574209; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=th38ntbA4Oc2oiVVTEFN7kVCZXMfBHW5bqzoJX/NKxM=; b=Qx1HMjnOH9OsA3ycuQn28p/IaZ+Hp3kNuLp2QUi9h0Ycfnoty+yQNpg+WRxNuY/vYp jOY7XFohXtJylm8Zhy5PNGpA0U7IS0oAfCING0t+nz1L/hwrLlAjdn6QB4BQ7g4vN6HH OAiYlZHTTmYK4E/ibEh6T98sf4VZmgYow+qhvCLJm9G0PRCymGehRtI1hbaEgguuPSwP c7t1cNU/lIriIMXf5vdSZTLjo71hA+1rjgeHrdym+NEDcQOTi8Gy7EZ3GPG7NMQg7zho MG8uusZE7ELVwRFmlhIaXFZ9jTXMsB870R8rLfTvIx/zMtY4Y5kaKuhA8atMfdGBrjnt RIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677574209; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=th38ntbA4Oc2oiVVTEFN7kVCZXMfBHW5bqzoJX/NKxM=; b=ObC1h4bpj3igu82H3vkJPX3H3VJOoEngi7EozA66PoX0K+RkItC6iBgZox6AOjxhQx +LkPwoml/+ReSS5ZCcj5Gozk03UlceXBytAgJlWLaMGV02HGGcixykBQG1zffW1z5qQF eZCbozOC6D1GLSf73gZkd54AGNWCFNhJ9uRv3h6tRVph3sTWDT5625rqApaLv2RQ7L/O 5FA65bxEjwVm8vDIvak8VPavHoD4MkI5JEhid2rg27pJ3C18lLrgxC1+9eedb6S274Ax 1YmBEMdVVJ5857ihxk2Aiarm2/Prd55bTadwFgKhbSQPTv/jEUrszOe7hgWEJ2QgrMs7 3GGg== X-Gm-Message-State: AO0yUKXXHWuwOBJr+WAo3jKzry0OYDtP/t/M1aS+LUvenyj/Zw+I18Sa q5UULMdlnJ3Xy6SDIdHo56rYuEihynDIZMzN X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a81:ad67:0:b0:525:2005:7dc2 with SMTP id l39-20020a81ad67000000b0052520057dc2mr1184169ywk.1.1677574209698; Tue, 28 Feb 2023 00:50:09 -0800 (PST) Date: Tue, 28 Feb 2023 08:50:02 +0000 In-Reply-To: <20230228085002.2592473-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20230228085002.2592473-1-yosryahmed@google.com> X-Mailer: git-send-email 2.39.2.722.g9855ee24e9-goog Message-ID: <20230228085002.2592473-3-yosryahmed@google.com> Subject: [PATCH v1 2/2] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim From: Yosry Ahmed <yosryahmed@google.com> To: Alexander Viro <viro@zeniv.linux.org.uk>, "Darrick J. Wong" <djwong@kernel.org>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Vlastimil Babka <vbabka@suse.cz>, Roman Gushchin <roman.gushchin@linux.dev>, Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, Miaohe Lin <linmiaohe@huawei.com>, David Hildenbrand <david@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, Peter Xu <peterx@redhat.com>, NeilBrown <neilb@suse.de>, Shakeel Butt <shakeelb@google.com>, Michal Hocko <mhocko@kernel.org> Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed <yosryahmed@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759065909456247254?= X-GMAIL-MSGID: =?utf-8?q?1759065909456247254?= |
Series |
Ignore non-LRU-based reclaim in memcg reclaim
|
|
Commit Message
Yosry Ahmed
Feb. 28, 2023, 8:50 a.m. UTC
We keep track of different types of reclaimed pages through
reclaim_state->reclaimed, and we add them to the reported number of
reclaimed pages. For non-memcg reclaim, this makes sense. For memcg
reclaim, we have no clue if those pages are charged to the memcg under
reclaim.
Slab pages are shared by different memcgs, so a freed slab page may have
only been partially charged to the memcg under reclaim. The same goes
for clean file pages from pruned inodes (on highmem systems) or xfs
buffer pages, there is no way to link them to the memcg under reclaim.
Stop reporting those freed pages as reclaimed pages during memcg
reclaim. This should make the return value of writing to memory.reclaim,
and may help reduce unnecessary reclaim retries during memcg charging.
Generally, this should make the return value of
try_to_free_mem_cgroup_pages() more accurate. In some limited cases (e.g.
freed a slab page that was mostly charged to the memcg under reclaim),
the return value of try_to_free_mem_cgroup_pages() can be
underestimated, but this should be fine. The freed pages will be
uncharged anyway, and we can charge the memcg the next time around as we
usually do memcg reclaim in a retry loop.
Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
---
mm/vmscan.c | 50 +++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 11 deletions(-)
Comments
Hi Yosry, Thank you for the patch! Yet something to improve: [auto build test ERROR on akpm-mm/mm-everything] [cannot apply to vbabka-slab/for-next xfs-linux/for-next v6.2] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20230228085002.2592473-3-yosryahmed%40google.com patch subject: [PATCH v1 2/2] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim config: x86_64-randconfig-a014-20230227 (https://download.01.org/0day-ci/archive/20230228/202302281959.EmOJaeae-lkp@intel.com/config) compiler: gcc-11 (Debian 11.3.0-8) 11.3.0 reproduce (this is a W=1 build): # https://github.com/intel-lab-lkp/linux/commit/f6d2b849f186a927925a29e289d60895048550f5 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 git checkout f6d2b849f186a927925a29e289d60895048550f5 # save the config file mkdir build_dir && cp config build_dir/.config make W=1 O=build_dir ARCH=x86_64 olddefconfig make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot <lkp@intel.com> | Link: https://lore.kernel.org/oe-kbuild-all/202302281959.EmOJaeae-lkp@intel.com/ All errors (new ones prefixed by >>): >> mm/vmscan.c:549:13: error: redefinition of 'cgroup_reclaim' 549 | static bool cgroup_reclaim(struct scan_control *sc) | ^~~~~~~~~~~~~~ mm/vmscan.c:191:13: note: previous definition of 'cgroup_reclaim' with type 'bool(struct scan_control *)' {aka '_Bool(struct scan_control *)'} 191 | static bool cgroup_reclaim(struct scan_control *sc) | ^~~~~~~~~~~~~~ >> mm/vmscan.c:554:13: error: redefinition of 'global_reclaim' 554 | static bool global_reclaim(struct scan_control *sc) | ^~~~~~~~~~~~~~ mm/vmscan.c:196:13: note: previous definition of 'global_reclaim' with type 'bool(struct scan_control *)' {aka '_Bool(struct scan_control *)'} 196 | static bool global_reclaim(struct scan_control *sc) | ^~~~~~~~~~~~~~ mm/vmscan.c:196:13: warning: 'global_reclaim' defined but not used [-Wunused-function] vim +/cgroup_reclaim +549 mm/vmscan.c 86750830468506 Yang Shi 2021-05-04 548 b5ead35e7e1d34 Johannes Weiner 2019-11-30 @549 static bool cgroup_reclaim(struct scan_control *sc) 89b5fae5368f6a Johannes Weiner 2012-01-12 550 { b5ead35e7e1d34 Johannes Weiner 2019-11-30 551 return false; 89b5fae5368f6a Johannes Weiner 2012-01-12 552 } 97c9341f727105 Tejun Heo 2015-05-22 553 a579086c99ed70 Yu Zhao 2022-12-21 @554 static bool global_reclaim(struct scan_control *sc) a579086c99ed70 Yu Zhao 2022-12-21 555 { a579086c99ed70 Yu Zhao 2022-12-21 556 return true; a579086c99ed70 Yu Zhao 2022-12-21 557 } a579086c99ed70 Yu Zhao 2022-12-21 558
Hi Yosry, Thank you for the patch! Yet something to improve: [auto build test ERROR on akpm-mm/mm-everything] [also build test ERROR on linus/master next-20230228] [cannot apply to vbabka-slab/for-next xfs-linux/for-next v6.2] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything patch link: https://lore.kernel.org/r/20230228085002.2592473-3-yosryahmed%40google.com patch subject: [PATCH v1 2/2] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim config: i386-randconfig-a002-20230227 (https://download.01.org/0day-ci/archive/20230228/202302281933.vU1PHuZr-lkp@intel.com/config) compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/f6d2b849f186a927925a29e289d60895048550f5 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 git checkout f6d2b849f186a927925a29e289d60895048550f5 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot <lkp@intel.com> | Link: https://lore.kernel.org/oe-kbuild-all/202302281933.vU1PHuZr-lkp@intel.com/ All errors (new ones prefixed by >>): >> mm/vmscan.c:549:13: error: redefinition of 'cgroup_reclaim' static bool cgroup_reclaim(struct scan_control *sc) ^ mm/vmscan.c:191:13: note: previous definition is here static bool cgroup_reclaim(struct scan_control *sc) ^ >> mm/vmscan.c:554:13: error: redefinition of 'global_reclaim' static bool global_reclaim(struct scan_control *sc) ^ mm/vmscan.c:196:13: note: previous definition is here static bool global_reclaim(struct scan_control *sc) ^ 2 errors generated. vim +/cgroup_reclaim +549 mm/vmscan.c 86750830468506 Yang Shi 2021-05-04 548 b5ead35e7e1d34 Johannes Weiner 2019-11-30 @549 static bool cgroup_reclaim(struct scan_control *sc) 89b5fae5368f6a Johannes Weiner 2012-01-12 550 { b5ead35e7e1d34 Johannes Weiner 2019-11-30 551 return false; 89b5fae5368f6a Johannes Weiner 2012-01-12 552 } 97c9341f727105 Tejun Heo 2015-05-22 553 a579086c99ed70 Yu Zhao 2022-12-21 @554 static bool global_reclaim(struct scan_control *sc) a579086c99ed70 Yu Zhao 2022-12-21 555 { a579086c99ed70 Yu Zhao 2022-12-21 556 return true; a579086c99ed70 Yu Zhao 2022-12-21 557 } a579086c99ed70 Yu Zhao 2022-12-21 558
On Tue, Feb 28, 2023 at 3:56 AM kernel test robot <lkp@intel.com> wrote: > > Hi Yosry, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on akpm-mm/mm-everything] > [also build test ERROR on linus/master next-20230228] > [cannot apply to vbabka-slab/for-next xfs-linux/for-next v6.2] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything > patch link: https://lore.kernel.org/r/20230228085002.2592473-3-yosryahmed%40google.com > patch subject: [PATCH v1 2/2] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim > config: i386-randconfig-a002-20230227 (https://download.01.org/0day-ci/archive/20230228/202302281933.vU1PHuZr-lkp@intel.com/config) > compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://github.com/intel-lab-lkp/linux/commit/f6d2b849f186a927925a29e289d60895048550f5 > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 > git checkout f6d2b849f186a927925a29e289d60895048550f5 > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot <lkp@intel.com> > | Link: https://lore.kernel.org/oe-kbuild-all/202302281933.vU1PHuZr-lkp@intel.com/ > > All errors (new ones prefixed by >>): > > >> mm/vmscan.c:549:13: error: redefinition of 'cgroup_reclaim' > static bool cgroup_reclaim(struct scan_control *sc) > ^ > mm/vmscan.c:191:13: note: previous definition is here > static bool cgroup_reclaim(struct scan_control *sc) > ^ > >> mm/vmscan.c:554:13: error: redefinition of 'global_reclaim' > static bool global_reclaim(struct scan_control *sc) > ^ > mm/vmscan.c:196:13: note: previous definition is here > static bool global_reclaim(struct scan_control *sc) > ^ > 2 errors generated. Ugh yeah I didn't realize I am moving the definitions from within an #ifdef CONFIG_MEMCG. I will just leave the definitions as-is and add a forward declaration before the definition of add_non_vmscan_reclaimed(), should also reduce the churn in the diff. Will wait for a bit before re-spinning to gather some feedback on the current version first. > > > vim +/cgroup_reclaim +549 mm/vmscan.c > > 86750830468506 Yang Shi 2021-05-04 548 > b5ead35e7e1d34 Johannes Weiner 2019-11-30 @549 static bool cgroup_reclaim(struct scan_control *sc) > 89b5fae5368f6a Johannes Weiner 2012-01-12 550 { > b5ead35e7e1d34 Johannes Weiner 2019-11-30 551 return false; > 89b5fae5368f6a Johannes Weiner 2012-01-12 552 } > 97c9341f727105 Tejun Heo 2015-05-22 553 > a579086c99ed70 Yu Zhao 2022-12-21 @554 static bool global_reclaim(struct scan_control *sc) > a579086c99ed70 Yu Zhao 2022-12-21 555 { > a579086c99ed70 Yu Zhao 2022-12-21 556 return true; > a579086c99ed70 Yu Zhao 2022-12-21 557 } > a579086c99ed70 Yu Zhao 2022-12-21 558 > > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests
On Tue, Feb 28, 2023 at 9:18 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > On Tue, Feb 28, 2023 at 3:56 AM kernel test robot <lkp@intel.com> wrote: > > > > Hi Yosry, > > > > Thank you for the patch! Yet something to improve: > > > > [auto build test ERROR on akpm-mm/mm-everything] > > [also build test ERROR on linus/master next-20230228] > > [cannot apply to vbabka-slab/for-next xfs-linux/for-next v6.2] > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > And when submitting patch, we suggest to use '--base' as documented in > > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > > > url: https://github.com/intel-lab-lkp/linux/commits/Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 > > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything > > patch link: https://lore.kernel.org/r/20230228085002.2592473-3-yosryahmed%40google.com > > patch subject: [PATCH v1 2/2] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim > > config: i386-randconfig-a002-20230227 (https://download.01.org/0day-ci/archive/20230228/202302281933.vU1PHuZr-lkp@intel.com/config) > > compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) > > reproduce (this is a W=1 build): > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # https://github.com/intel-lab-lkp/linux/commit/f6d2b849f186a927925a29e289d60895048550f5 > > git remote add linux-review https://github.com/intel-lab-lkp/linux > > git fetch --no-tags linux-review Yosry-Ahmed/mm-vmscan-refactor-updating-reclaimed-pages-in-reclaim_state/20230228-165214 > > git checkout f6d2b849f186a927925a29e289d60895048550f5 > > # save the config file > > mkdir build_dir && cp config build_dir/.config > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash > > > > If you fix the issue, kindly add following tag where applicable > > | Reported-by: kernel test robot <lkp@intel.com> > > | Link: https://lore.kernel.org/oe-kbuild-all/202302281933.vU1PHuZr-lkp@intel.com/ > > > > All errors (new ones prefixed by >>): > > > > >> mm/vmscan.c:549:13: error: redefinition of 'cgroup_reclaim' > > static bool cgroup_reclaim(struct scan_control *sc) > > ^ > > mm/vmscan.c:191:13: note: previous definition is here > > static bool cgroup_reclaim(struct scan_control *sc) > > ^ > > >> mm/vmscan.c:554:13: error: redefinition of 'global_reclaim' > > static bool global_reclaim(struct scan_control *sc) > > ^ > > mm/vmscan.c:196:13: note: previous definition is here > > static bool global_reclaim(struct scan_control *sc) > > ^ > > 2 errors generated. > > Ugh yeah I didn't realize I am moving the definitions from within an > #ifdef CONFIG_MEMCG. I will just leave the definitions as-is and add a > forward declaration before the definition of > add_non_vmscan_reclaimed(), should also reduce the churn in the diff. > Will wait for a bit before re-spinning to gather some feedback on the > current version first. I can also just move all the reclaim state functions (set_task_reclaim_state(), report_freed_pages(), add_non_vmscan_reclaimed()) below that #ifdef CONFIG_MEMCG. Might also name them more consistently. > > > > > > > vim +/cgroup_reclaim +549 mm/vmscan.c > > > > 86750830468506 Yang Shi 2021-05-04 548 > > b5ead35e7e1d34 Johannes Weiner 2019-11-30 @549 static bool cgroup_reclaim(struct scan_control *sc) > > 89b5fae5368f6a Johannes Weiner 2012-01-12 550 { > > b5ead35e7e1d34 Johannes Weiner 2019-11-30 551 return false; > > 89b5fae5368f6a Johannes Weiner 2012-01-12 552 } > > 97c9341f727105 Tejun Heo 2015-05-22 553 > > a579086c99ed70 Yu Zhao 2022-12-21 @554 static bool global_reclaim(struct scan_control *sc) > > a579086c99ed70 Yu Zhao 2022-12-21 555 { > > a579086c99ed70 Yu Zhao 2022-12-21 556 return true; > > a579086c99ed70 Yu Zhao 2022-12-21 557 } > > a579086c99ed70 Yu Zhao 2022-12-21 558 > > > > -- > > 0-DAY CI Kernel Test Service > > https://github.com/intel/lkp-tests
diff --git a/mm/vmscan.c b/mm/vmscan.c index 8846531e85a4..c53659221965 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -188,6 +188,16 @@ struct scan_control { */ int vm_swappiness = 60; +static bool cgroup_reclaim(struct scan_control *sc) +{ + return sc->target_mem_cgroup; +} + +static bool global_reclaim(struct scan_control *sc) +{ + return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); +} + static void set_task_reclaim_state(struct task_struct *task, struct reclaim_state *rs) { @@ -217,7 +227,35 @@ EXPORT_SYMBOL(report_freed_pages); static void add_non_vmscan_reclaimed(struct scan_control *sc, struct reclaim_state *rs) { - if (rs) { + /* + * Currently, reclaim_state->reclaimed includes three types of pages + * freed outside of vmscan: + * (1) Slab pages. + * (2) Clean file pages from pruned inodes. + * (3) XFS freed buffer pages. + * + * For all of these cases, we have no way of finding out whether these + * pages were related to the memcg under reclaim. For example, a freed + * slab page could have had only a single object charged to the memcg + * under reclaim. Also, populated inodes are not on shrinker LRUs + * anymore except on highmem systems. + * + * Instead of over-reporting the reclaimed pages in a memcg reclaim, + * only count such pages in system-wide reclaim. This prevents + * unnecessary retries during memcg charging and false positive from + * proactive reclaim (memory.reclaim). + * + * For uncommon cases were the freed pages were actually significantly + * charged to the memcg under reclaim, and we end up under-reporting, it + * should be fine. The freed pages will be uncharged anyway, even if + * they are not reported properly, and we will be able to make forward + * progress in charging (which is usually in a retry loop). + * + * We can go one step further, and report the uncharged objcg pages in + * memcg reclaim, to make reporting more accurate and reduce + * under-reporting, but it's probably not worth the complexity for now. + */ + if (rs && !cgroup_reclaim(sc)) { sc->nr_reclaimed += rs->reclaimed; rs->reclaimed = 0; } @@ -463,16 +501,6 @@ void reparent_shrinker_deferred(struct mem_cgroup *memcg) up_read(&shrinker_rwsem); } -static bool cgroup_reclaim(struct scan_control *sc) -{ - return sc->target_mem_cgroup; -} - -static bool global_reclaim(struct scan_control *sc) -{ - return !sc->target_mem_cgroup || mem_cgroup_is_root(sc->target_mem_cgroup); -} - /** * writeback_throttling_sane - is the usual dirty throttling mechanism available? * @sc: scan_control in question