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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F605C76196 for ; Fri, 31 Mar 2023 07:25:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3C646B0071; Fri, 31 Mar 2023 03:25:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEBD76B0072; Fri, 31 Mar 2023 03:25:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBE686B0074; Fri, 31 Mar 2023 03:25:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AB9976B0071 for ; Fri, 31 Mar 2023 03:25:54 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 74820C01DC for ; Fri, 31 Mar 2023 07:25:54 +0000 (UTC) X-FDA: 80628359028.18.948D92C Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf20.hostedemail.com (Postfix) with ESMTP id A4CDD1C0006 for ; Fri, 31 Mar 2023 07:25:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BD2fSO1i; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680247552; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pw4kStS7rzbbLRqrWs4BjnS/rfPwq6lyL0n3r//piM4=; b=39g7vG099KfR+luBeRhFYlJSJ2iAnN+bRoRB3zMZiQDtcd3+/v6cnHmS+WvuciJS3RUGfg 6eLu9GMUnLvQDabt4x6gGFQk5xeGLteL1A64l1F46cS4tY+ZQrtWPAAlQHtkOUKrE+NWDT eDFVbgkbF7Dpr2cirg9c1vwQbXhZuPU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BD2fSO1i; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680247552; a=rsa-sha256; cv=none; b=0ysBUOEHTqmVpY7V7SH978EQkp13S6Xc7e5oNyEOygxa38ixHImsRfWpt38897E/Mafz5d 5VWpSRAAqbdwKGVTqy3wXSzRkRwR+z15oxBEPJjs05QRUyZrcnh12c3GSvOXXY0eBTXI/W ZD/675HyAsl6tsYUe0nAVS32Fw+egK8= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-3ee6c339cceso153315e9.0 for ; Fri, 31 Mar 2023 00:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680247551; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pw4kStS7rzbbLRqrWs4BjnS/rfPwq6lyL0n3r//piM4=; b=BD2fSO1ioVmfH8kTUKFk4RCIgml6T+ntV2pSMl6FqHKLjBbsMywpSB7JFDCoHurnLI V9o1X7oCj9Jv5ac882+AMXAfxTwK6hLy+/NK3ZJi40FJTY+CbC1IQQLS+YMLkwbtbzOw H3sh2XMfB1LLIlPQbZUAdPb93N3AvQGMds9a+yyZpaDSCaJRwSpUPqMLTuR1u3z+/Ur5 68nP8o+u0Th7+o5O4AlPzpPsLH/f/sblbW/IGfzEWBSXq4hUwKdloV4cMx/+7YLbpiPM pAqmx55DTfBdGh74Xl6PY3KG+bjnX/S2cqxeLC1pOy22SVlDFDHPpiwk8k6bVUcElsQ3 dWwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680247551; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pw4kStS7rzbbLRqrWs4BjnS/rfPwq6lyL0n3r//piM4=; b=W7V81ShWuQ9TNVyTHznC90TB+IsmIPWMQGN73UjfNAtmqkcDViE7em5ZwCvJYDOxER +To7NG3ZLcMamqS6+E/yRLHwwIolYL+gS1WyJcFBZ7Q7/k+jaj7DsRvt+BGCKKzzbzYq GXIlz6Yv460cl4Mpdg7Fxm2blDUzKe4eNl+VzNFMIO3kfSSfDXY3kDB64B0kuhVTptzU CwJZr9FtQ3Gyhn+scRp8iKWQCTMi6Sd/qrloltf8pgIEPs0YsIrTgO7wRjHF3E8mJ790 ZJa0ecYV9c+wuCaED9lzbBwlD5MzYxbXLby7GI78It6AEcRVNPyItQmD11F/6psIVQK3 lm6g== X-Gm-Message-State: AAQBX9daoflNurw83YVLXQIVh8oe4rKRYtJBOu4Z6xLWwV697IbfRB7O AFBgbc3WEc0eXj41thuMu7K8f1p9cvXe/CnYLOHI2A== X-Google-Smtp-Source: AKy350abOVAkC/dx0dxQVe8vtvq9YDRYyGvhn/EWZ6txiXHe82kTuCLaKsXWJ3VDTDrFx6WCn8woIMYCmAHVCwAovDk= X-Received: by 2002:a05:600c:1e26:b0:3df:f3ce:be44 with SMTP id ay38-20020a05600c1e2600b003dff3cebe44mr81129wmb.3.1680247551038; Fri, 31 Mar 2023 00:25:51 -0700 (PDT) MIME-Version: 1.0 References: <20230331070818.2792558-1-yosryahmed@google.com> <20230331070818.2792558-4-yosryahmed@google.com> In-Reply-To: <20230331070818.2792558-4-yosryahmed@google.com> From: Yu Zhao Date: Fri, 31 Mar 2023 01:25:14 -0600 Message-ID: Subject: Re: [PATCH v3 3/3] mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim To: Yosry Ahmed Cc: Andrew Morton , Alexander Viro , "Darrick J. Wong" , Christoph Lameter , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Matthew Wilcox (Oracle)" , Miaohe Lin , David Hildenbrand , Johannes Weiner , Peter Xu , NeilBrown , Shakeel Butt , Michal Hocko , Dave Chinner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A4CDD1C0006 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: r9rd1rhgpn8y17e97z1s6stfift6mycu X-HE-Tag: 1680247552-829745 X-HE-Meta: U2FsdGVkX18LjO2GUtA3+eYRScYZfZzH6ql5IazlUVpSheraTbpVHx++uCQHY5lR+FsRrj+irgtcLcaFDwkf7mZVvh9DLGTDQ4nT39ovpZ7Jt4QqGwUL7v1Pm1ltM0UGt4VaEoq6Jyz1qXZ2Ly/oEMfnz9eAXp2HWFLcqRhNCuZISJJgvg9coZbQdrJ4FaGZjP2mGk8GLQSsdq4ii6d8lWdc+UbsrSBIOIUlHWKinJs0E4G8CZvnLwy7ThLZBNvLUbSc3Xmm6sbmtYBuv8tBj9Gyqk6Z3Zlc3Fo8s1cugFxwkNB41bYoFQ30NlSVv/fGHZYJn0XFgbQCMQr37nc5uI/3F/lxcogfF5hSs8X0+sid7UkH6dEuF+qgGixzS6piF85KTHBuloLE8UO+NpPLwQkPJMbj5KI5dUOKKwcfyhWRXH686JXq6l351kKl4O+98wqhXZ2xTXL2XBrEGoYksRxp/BuBpq6ixqaZb3/TXqQTFb7e69r6LL6whI0TQO3y4YQWue7FAwFqXfX1q0jXZLKvSEhs31iSREhEh9Gp2G51g8oHxGf7YbN1i3omP9kgrQiGiTC5hIr+Dh0Gwvic9TkjhWgGeDTEiS1i/lU0tHzX6twtxgPCSsFbJd5vWxfR7UnI1bkXXZLdviNrCFr0nfQcKDCvDbnsKq15W5fYSpA3PtQRR3pl3J1dzmEUJSBsyAhe5eWcHKeI9NQp8gPLhu9mHp4/C3ZuzC9uMEDJ796dT4uIV6MwCzJgQJzVVSnWxIvDtdkjmEmIClEuitW8x/v+lf2RuI9zvbgblnX+E0KxTeCaethhI6/s2HbddP6B2wu6C3GqOl1xJHjMoy2ZZuI9nZHnY4bWv1JzmSWWTHxoJXvQDKB2ustzZXFMzZBE6SrbAw+YyGlQ3/H5PCa3Gp7QQ1waSTwtZfaUp0iG4K6IOVaJAMdLM8WYdd5ecQ4F3p7dXLMb4f1HCmfi5P+ ltAKu6+m OW712yCJHZK5K4p/BmuvDdCOrnmzysJJBkZHcndklwVTVX84oxPnvoexZjFh0pCAEV0tqGw83lBaVkkEXuvTwj5XvtQxNKqfAJtCy0FHowRjFb+tzAceO9LT74XXC8XOw3AV0bx5/6PFn5E2YpKa2Iv3C8+Q0aTEvX4C2aRif1uewsc5ZmxsrM+/hz7Ad800WFBCg/KogkjszF3uFOHe659Q7k1xx/fDAVSUuL8ixzEIozO7TWCDBONH+3JVd0K+dIJSi11xRs8aE8JuTfH9YCFF3tvVT2HguEKLEnOGN5tN11BMDjTNa8Gz7knUKCvY4tqc7D/hgMolont8CTuiEbnyngQ== 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 Fri, Mar 31, 2023 at 1:08=E2=80=AFAM Yosry Ahmed = wrote: ... > diff --git a/mm/vmscan.c b/mm/vmscan.c > index a3e38851b34ac..bf9d8e175e92a 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -533,7 +533,35 @@ EXPORT_SYMBOL(mm_account_reclaimed_pages); > static void flush_reclaim_state(struct scan_control *sc, > struct reclaim_state *rs) > { > - if (rs) { > + /* > + * Currently, reclaim_state->reclaimed includes three types of pa= ges > + * 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 m= emcg > + * 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 recla= im, > + * only count such pages in system-wide reclaim. This prevents > + * unnecessary retries during memcg charging and false positive f= rom > + * proactive reclaim (memory.reclaim). What happens when writing to the root memory.reclaim? > + * > + * For uncommon cases were the freed pages were actually signific= antly > + * charged to the memcg under reclaim, and we end up under-report= ing, 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 fo= rward > + * progress in charging (which is usually in a retry loop). > + * > + * We can go one step further, and report the uncharged objcg pag= es in > + * memcg reclaim, to make reporting more accurate and reduce > + * under-reporting, but it's probably not worth the complexity fo= r now. > + */ > + if (rs && !cgroup_reclaim(sc)) { To answer the question above, global_reclaim() would be preferred.