From patchwork Tue Apr 4 00:13:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yosry Ahmed X-Patchwork-Id: 13198930 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 80334C76188 for ; Tue, 4 Apr 2023 00:14:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 942C46B0071; Mon, 3 Apr 2023 20:13:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CC0D6B0074; Mon, 3 Apr 2023 20:13:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76C446B0075; Mon, 3 Apr 2023 20:13:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6276E6B0071 for ; Mon, 3 Apr 2023 20:13:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 37BBFAB5B5 for ; Tue, 4 Apr 2023 00:13:59 +0000 (UTC) X-FDA: 80641785798.19.643C434 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf07.hostedemail.com (Postfix) with ESMTP id 81F4840013 for ; Tue, 4 Apr 2023 00:13:57 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NgFr+mt8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3xGsrZAoKCHEndhgnPWbTSVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--yosryahmed.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3xGsrZAoKCHEndhgnPWbTSVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680567237; 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:in-reply-to: references:dkim-signature; bh=pu8NQW7PT3CX2ydDP6OKHn9xreaGc+GffyitQGTf/Sw=; b=5OLakmZW/czG2U+b8GQoIYtTVj4gs2c5UKiq3dN6r0wc37pc7isHu6c3xGtgnzPoOFgO3v UkM0BFvd1lN4AvVrrWbNhjHTCCk1V/tA1ZauEDmGA+IbQCGWWaskaIujvt0npnnyJFN2Y+ MfFAjhkuVerADQZob9uvA6ciCrCL+yU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NgFr+mt8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3xGsrZAoKCHEndhgnPWbTSVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--yosryahmed.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3xGsrZAoKCHEndhgnPWbTSVddVaT.RdbaXcjm-bbZkPRZ.dgV@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680567237; a=rsa-sha256; cv=none; b=dagSsTU3im5h4k9M7gHiilpHYlw5/TTv2osAhcl0HF5fbgHlvLPyjZkuBYOtw0uoqtiFqF vYkvN2Wk7YFQYZYzL/QjZppcrHoyhABvMdb/tdMTSFO+MmBQuFP9ZDRyuPWMaoFp2RFd6r EapwPUfcCRIclESkUBurKA9xIVumgCE= Received: by mail-yb1-f201.google.com with SMTP id y144-20020a253296000000b00b69ce0e6f2dso30411616yby.18 for ; Mon, 03 Apr 2023 17:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680567236; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=pu8NQW7PT3CX2ydDP6OKHn9xreaGc+GffyitQGTf/Sw=; b=NgFr+mt861ia/9ME3yYfnG6illl0smj1XxKWxv7RX7bCn30eK75+r3/mN045hxmTht XxXZE+TkL0kCi/mO3+BUA3w6mg7VHDQOKN2NVafTJLvv3QixFUE3R5iFK5w8ka0UMBGX cO3RgMHlOCZrZXeoyQngycjIG2W4nzC2svYLg3vadywoa9p2dHEu3QJDakNcoqZZYF0P gTi2ChtgNFu+gpwhTSXKUpPNbjfBCbDD3Ma4xYqGJ61C+BwiJAQfvfUnBTGy6XRnN+ue 2PE4ea3ZPsx5EJKDnp8qLdqYsi4/l4Nu9R12YsH4N7a6gS981iO1lmOd8TnhBeuT7CX0 zS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680567236; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pu8NQW7PT3CX2ydDP6OKHn9xreaGc+GffyitQGTf/Sw=; b=Uqwm/IxvcHlZGTPyjmC+0gbYmoRwK944LYrSLLgX1QiH+K7aegMEDWXYpKIR9caiW5 oLu7neydaDjtRuNPn3wbZmTktClWyvfeM/CbfcRDK48KfoW4BpZzkapahZCFbHx09yIw a0ElZhktun3sC2lncPnO7gA1ZnhrInRNGoacom6PbjmCO9cfo0hFBvK1/d2L7Hs2TdYE X0TgjV0MGKtunaGKHMwHklX1srhEGYYnFBkRWUgsp1ygjQeiHpm9GyU5tQQvinDMTkKd 9v9Jv/fahtxTpIRChZUZ8SZzSTNeDoOuNzkVrokIuVCjJLbo5dUoWWcN3yVvGC/nRkk4 5Npw== X-Gm-Message-State: AAQBX9dbRVpjbyuZhnePS/Jy6xiBX1iRDq6qlzi8aNWclKkKF6k6+8VA GwkgkAYdvcR57WLLr567VwcwKo/I5clqWVPg X-Google-Smtp-Source: AKy350bEZyh+kGC7zJpP2Eo/NB8JCiirULe8DAdhizlHAyh9HLDpxbXiafQS5oeVJeCFuCzpF+wkw4a2/+eTtkR9 X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a81:ac65:0:b0:545:bade:c590 with SMTP id z37-20020a81ac65000000b00545badec590mr463245ywj.1.1680567236548; Mon, 03 Apr 2023 17:13:56 -0700 (PDT) Date: Tue, 4 Apr 2023 00:13:50 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.40.0.348.gf938b09366-goog Message-ID: <20230404001353.468224-1-yosryahmed@google.com> Subject: [PATCH v4 0/3] Ignore non-LRU-based reclaim in memcg reclaim From: Yosry Ahmed To: 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 , Yu Zhao , Dave Chinner Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed X-Rspamd-Queue-Id: 81F4840013 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 9bfd4jypwau8mydrha9738xfsiaecxq9 X-HE-Tag: 1680567237-366419 X-HE-Meta: U2FsdGVkX18hSCoBuhGnd326vTHizGh4T6ImXIUhbtIPZs0FSFCWtAut8MF5UiF+89wLQxtX+us5bmxGBXSZmtBUzoiOGxDAD4BkEzjXdmxqNrS6Cow+UrDgbZ/7M0cu/JB6WCcVrvvd03Z9Gr26+OVzDudQEmUUdtGenSyUBjzIhI4frMbNTX2xqrcpOjlV16XdjMyrLKCMP6m6qWQOPe2+nVv8D+VPzEPrizUL1oKG6aSm1paBlTGTlicliILsl1wWo7+9IFFVlBmXtu1BjPMDqlz7Wap3rdptq3NhVhK6U9amm+UMgnc/NBxFKmvlefzZVuxj9NVr4WC79HbNEFOr4yT0aiyN36rCN9rYMCNXNEJaDZwQjFjUbnFxc1El/3awI4U+wp1ZVtLn3a2mpvq7WMqU/YXJl/ZiqjK2JxO+i2enTBvgJs1jceIjJjyo+l2/i6qLdGGY5XRJTtdhiro13MCQ4sZmri2F5uYNoNgU9BSJzbQuJB+nL4b0p9rGcaxPqvGOxRvA2TSLSm3+D0s7y/j+gsiIDPH1zPlaUgMlI/18xPbtrL/aBlLJHw3mnQiL5iqOzCBImrbaIPgARGZ1SuBq23fuu5j5SAAxuztEnA/J2aYpngJW25RQsJF5H60TsjtL7eWzm1wi1odRjQ7+yDYvEYTB//Gl3kiLLf0za2+B5Wg4NGQkOy246Vxi6qOTltsvQb6CEhd1BqvyDScyhlM9n2/Tjd6HHKSxrFcsHKrUtVuixPlJIFC0RJoTKc7DWuxoYgAoV/83KaptD8FQF7vswu008HqFT3eBzR1q7eAQGOhAw9L5qTZTDzliJ3UGLdSj+D+9d9BhY3/rjY3IzOn5FwfLQNJbcyd5nu0P23Ooie+iOHAxTg/VdyYvDeYkdXwj1uqR7A/9/t4dkxZDn4PjAa2X/OVcR6JJ9566vSY3Sd5TTwbyHh42yjvbf3StbdbWVYEyPhP5Xiy ne02mqoB gI32eH4K7SbwghzPt+/lR5mle/M5om2u5qxJDP80NhOBKm0xhSp85jZbgYPtO05Gh8x/665SQZCvHzCXbWe24fvyXm+EDhQ64mMayMEKwYhOSCfeTR0y2qilpo8/uMTjsObCrVkOPw0MIfcyAo4KApxydcc2RkspXGw3jOpFT3ArL2qTkLkLbBVDWpRHKmn5dQSw8VpuOFq+SZHKrNn973qCQydGjs0/DsagwfU2rk3v94HcvO75JIXvABxfhgjhl9NRujbiNzILkLtj7onCwqbRd+n+GY5p1KDlhxS3UQelKIhjHH2/6p8rns/i35Y11SE4G/4bqTpEn5Dgtp/LzJl/ndIMAWogN/irp3o5mwfzU+xHAN3Wkr1C62a+iWiXSiyEc8TtbOSR9Oivfw2ZiCzVEDbumDgwi+J16/K0QztMKYNCwfvvQwmZYCVnjrx5pxlcYKCC+ztdNntrAsXUMoxEzACYJBtEKR1cC3/W9kbYwzmz10aQuAKfvPuGxShD7rFGV5LxpcMHJNyIQ9kq6SopVX/vqKzxa1HtkQ7AC97/DsqZOsTshaFNyKkNDVNAFSj3hVSbLhzvKg0GmXYleDASMeNpZWyOeGWwWhcHezioKCbSfOOyYoSR/eXYzhuhlZdzo6rTakSHOBQiXw6H6OIOBOuFWKj8eHdAW8elPbHwWU95BT6K7pjP57QO4EUiam9rFHHgwygBf2fs= 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: Upon running some proactive reclaim tests using memory.reclaim, we noticed some tests flaking where writing to memory.reclaim would be successful even though we did not reclaim the requested amount fully. Looking further into it, I discovered that *sometimes* we over-report the number of reclaimed pages in memcg reclaim. Reclaimed pages through other means than LRU-based reclaim are tracked through reclaim_state in struct scan_control, which is stashed in current task_struct. These pages are added to the number of reclaimed pages through LRUs. For memcg reclaim, these pages generally cannot be linked to the memcg under reclaim and can cause an overestimated count of reclaimed pages. This short series tries to address that. Patches 1-2 are just refactoring, they add helpers that wrap some operations on current->reclaim_state, and rename reclaim_state->reclaimed_slab to reclaim_state->reclaimed. Patch 3 ignores pages reclaimed outside of LRU reclaim in memcg reclaim. The pages are uncharged anyway, so even if we end up under-reporting reclaimed pages we will still succeed in making progress during charging. Do not let the diff stat deceive you, the core of this series is patch 3, which has one line of code change. All the rest is refactoring and one huge comment. v3 -> v4: - Used global_reclaim() instead of !cgroup_reclaim() in patch 3 to include non-LRU reclaimed pages when writing to memory.reclaim for root (Yu Zhao). - Moved the definition of mm_account_reclaimed_pages() to a static inline in the header file (Dave Chinner). v2 -> v3: - Fixed a compilation problem in patch 2 reported by the bot. - Rebased on top of v6.3-rc2. v1 -> v2: - Renamed report_freed_pages() to mm_account_reclaimed_pages(), as suggested by Dave Chinner. There were discussions about leaving updating current->reclaim_state open-coded as it's not worth hiding the current dereferencing to remove one line, but I'd rather have the logic contained with mm/vmscan.c so that the next person that changes this logic doesn't have to change 7 different files. - Renamed add_non_vmscan_reclaimed() to flush_reclaim_state() (Johannes Weiner). - Added more context about how this problem was found in the cover letter (Johannes Weiner). - Added a patch to move set_task_reclaim_state() below the definition of cgroup_reclaim(), and added additional helpers in the same position. This way all the helpers for reclaim_state live together, and there is no need to declare cgroup_reclaim() early or move its definition around to call it from flush_reclaim_state(). This should also fix the build error reported by the bot in !CONFIG_MEMCG. RFC -> v1: - Exported report_freed_pages() in case XFS is built as a module (Matthew Wilcox). - Renamed reclaimed_slab to reclaim in previously missed MGLRU code. - Refactored using reclaim_state to update sc->nr_reclaimed into a helper and added an XL comment explaining why we ignore reclaim_state->reclaimed in memcg reclaim (Johannes Weiner). Yosry Ahmed (3): mm: vmscan: move set_task_reclaim_state() after global_reclaim() mm: vmscan: refactor updating reclaimed pages in reclaim_state mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim fs/inode.c | 3 +- fs/xfs/xfs_buf.c | 3 +- include/linux/swap.h | 17 ++++++++++- mm/slab.c | 3 +- mm/slob.c | 6 ++-- mm/slub.c | 5 ++- mm/vmscan.c | 73 +++++++++++++++++++++++++++++++++----------- 7 files changed, 78 insertions(+), 32 deletions(-)