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 6ABDAC433F5 for ; Wed, 5 Oct 2022 20:48:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5FEC6B0071; Wed, 5 Oct 2022 16:48:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0E7A8E0001; Wed, 5 Oct 2022 16:48:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD60A6B0074; Wed, 5 Oct 2022 16:48:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9C6F96B0071 for ; Wed, 5 Oct 2022 16:48:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4D2231A01F3 for ; Wed, 5 Oct 2022 20:48:23 +0000 (UTC) X-FDA: 79988083686.22.451A159 Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf17.hostedemail.com (Postfix) with ESMTP id ECE5340018 for ; Wed, 5 Oct 2022 20:48:22 +0000 (UTC) Received: by mail-ua1-f53.google.com with SMTP id x20so207077ual.6 for ; Wed, 05 Oct 2022 13:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=pH0zOlds4k1pn2k9y2zQLXOdbFwcJ2yiRKb/htjH3Uk=; b=FErrZMzivjR/A5E21MQn1/2DXduzHVWRROGe6Ud2gjscvz10sql8a5gaj4ZD9xSVNA dRXymD67ilwrVSpkDTL1H7ylxFC9pYd5v8NEYKLasINuw1TmiBeEN/mvHu7qICAYTImQ ka5uL0ncuFTlmRm+6hHIQ8Ma/zzn9dBJr29jm8qai3w/UZv82Q4CFeUMwzTJRTQlnO5Z pbo78ytl4764MoBLJZ7Pk9DqkeS6bGKMYc8z9/drFxdZH9SxPDuk4dvvmVE0jUQWs8ws W9iL7p9O4vr/dX+J9EL1DxXuM4hP/Vfq6OsFjBGOh6oSf52rB8x/J8TujBSrtukQ954H w2/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=pH0zOlds4k1pn2k9y2zQLXOdbFwcJ2yiRKb/htjH3Uk=; b=Z8W9gYx4ej1N7cBPYmzOV1H6xWZkcu4QL0R1w9GVgCyQj0V7jJo5ah20MeH1ma1uOK oE+/BEboGonGycCRal5jCchs/cWAeGcpHPqvRxYIgHfm7t7yZ77cLgkldVoHNSI0vm6c U5sKwkcTtzTCuhF1avilX6ffoR2CfeqAd87589mF2vM42nThiOPTbhmW/AUPwhm5SFix jZ2ok9JlxM7BL8imttmnTNqz/aJjv3Xn3aijt5tV/CxukM2mQ/+bMwhBazLnE54GBhAw j85ukHjbarmQa266BEaoDB2YLxtRXwRs4uucjv1hUVdKtNUp9NZRHkwDbCe/LbMveF37 /8gA== X-Gm-Message-State: ACrzQf25GkQoay3ADpfe0kXhVsnF0kpWwxQOGuk8dO6lI5B7GT7QJjj9 gz9ZsuvxNw6AaySRkjUH6wwTzpjwT33Sq9zU4royvQ== X-Google-Smtp-Source: AMsMyM6aTCliTCNY0L3OfUC8MMYfTb5EC3wVMouU8hxv59dCZ3tOJB0Dj+k0ZL1fw1l6+vgk5PoBTP30v9tv23NkiUg= X-Received: by 2002:ab0:6f94:0:b0:3d1:d6e5:5de6 with SMTP id f20-20020ab06f94000000b003d1d6e55de6mr837772uav.51.1665002902081; Wed, 05 Oct 2022 13:48:22 -0700 (PDT) MIME-Version: 1.0 References: <20221005173713.1308832-1-yosryahmed@google.com> In-Reply-To: <20221005173713.1308832-1-yosryahmed@google.com> From: Yu Zhao Date: Wed, 5 Oct 2022 14:47:46 -0600 Message-ID: Subject: Re: [PATCH v2] mm/vmscan: check references from all memcgs for swapbacked memory To: Yosry Ahmed Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Greg Thelen , David Rientjes , Cgroups , Linux-MM Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665002903; 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:in-reply-to:references:references:dkim-signature; bh=pH0zOlds4k1pn2k9y2zQLXOdbFwcJ2yiRKb/htjH3Uk=; b=W6vZzFM+ACbUI8v5oPa/Uov/ykYkF/WJhnr34A904MPJIdMBnXqBLR88wqdCU5lKY3pZwC zPZ6+pFygbTn5UBRWXIAYzS8PzvR3F7NMeYGrsVYwVwYI3P8HeyaK6QeNxkNUQSxiJ9qr0 RYFBJK+cUCgjNmWJYP3edH7OoArYq3w= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FErrZMzi; spf=pass (imf17.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665002903; a=rsa-sha256; cv=none; b=Rrwz5/Ni2V4Xc0hVqNcYESicgskApTENS8/+XNIpiJG2baD1AglPtpkGIixNjbgxpUeg5m NPfFKm0mfhgK95RSNm1ZP3v/56to6E7vMj90tfWy47Yb7VWp3KAnW0FIK+G9WxT8Uu94NS NW9JJhmEf5bUVQLrLFuKWIJT40U0pzk= X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FErrZMzi; spf=pass (imf17.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.53 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: k19otw5kso6rxqf9c6nornrerw6w1wis X-Rspamd-Queue-Id: ECE5340018 X-Rspamd-Server: rspam02 X-HE-Tag: 1665002902-879318 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, Oct 5, 2022 at 11:37 AM Yosry Ahmed wrote: > > During page/folio reclaim, we check if a folio is referenced using > folio_referenced() to avoid reclaiming folios that have been recently > accessed (hot memory). The rationale is that this memory is likely to be > accessed soon, and hence reclaiming it will cause a refault. > > For memcg reclaim, we currently only check accesses to the folio from > processes in the subtree of the target memcg. This behavior was > originally introduced by commit bed7161a519a ("Memory controller: make > page_referenced() cgroup aware") a long time ago. Back then, refaulted > pages would get charged to the memcg of the process that was faulting them > in. It made sense to only consider accesses coming from processes in the > subtree of target_mem_cgroup. If a page was charged to memcg A but only > being accessed by a sibling memcg B, we would reclaim it if memcg A is > is the reclaim target. memcg B can then fault it back in and get charged > for it appropriately. > > Today, this behavior still makes sense for file pages. However, unlike > file pages, when swapbacked pages are refaulted they are charged to the > memcg that was originally charged for them during swapping out. Which > means that if a swapbacked page is charged to memcg A but only used by > memcg B, and we reclaim it from memcg A, it would simply be faulted back > in and charged again to memcg A once memcg B accesses it. In that sense, > accesses from all memcgs matter equally when considering if a swapbacked > page/folio is a viable reclaim target. > > Modify folio_referenced() to always consider accesses from all memcgs if > the folio is swapbacked. It seems to me this change can potentially increase the number of zombie memcgs. Any risk assessment done on this?