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 00DC2C3DA6E for ; Fri, 5 Jan 2024 07:33:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5354D6B02F1; Fri, 5 Jan 2024 02:33:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E3586B02F2; Fri, 5 Jan 2024 02:33:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AA6B8D0018; Fri, 5 Jan 2024 02:33:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 23B146B02F1 for ; Fri, 5 Jan 2024 02:33:30 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E4888A1FFB for ; Fri, 5 Jan 2024 07:33:29 +0000 (UTC) X-FDA: 81644442138.25.54E7439 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf20.hostedemail.com (Postfix) with ESMTP id 1FC511C0002 for ; Fri, 5 Jan 2024 07:33:27 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cPg7gREz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704440008; 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=aHicSr6rOWVvMTesmGW7ZwN5Nw8dTnXVRJbiDId9Yc8=; b=GMOyCl7GE9EnplT7rIQ7UTD6Dq7RA3bDc10YyIbkYj5cV/V8OnGKFF9B/rTfSJGJMfdTb5 0WYttdlCNEtQhuAtG2IllLK/VZScP+zo2Z1Xa1WcbHGv8O9MMzx42yjzD9DDP9cNqiACbc weqHUAmpUadiyDjD/5WU1yUP38/HcMo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cPg7gREz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704440008; a=rsa-sha256; cv=none; b=v+a3od3vwc7h+/o/005Q8rI7+f2IBY4XeMtrm1jnk4SSBszM5fSrA7li2vnhx0Il3a7vqt mTY38ZZ1c5i6kiInIEuL9OVx5tKwz0NBCgXCvJronTaFb66xuD4cX02EWSa8egMhZzXBfL x4171v7o9sPhkXSFDdbA/KE3VCrs7+w= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2ccea11b6bbso3025391fa.0 for ; Thu, 04 Jan 2024 23:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704440006; x=1705044806; darn=kvack.org; 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=aHicSr6rOWVvMTesmGW7ZwN5Nw8dTnXVRJbiDId9Yc8=; b=cPg7gREzLGDES/RAeVYbP4sq8TAEMvolJ80yr4KO+6ph3Hb4u3+g364Z4ZBFU60RnN XygW1sBe81laQq8u23OFu7nPXFN8el/mbOf9O5wLXRAGaqzuIIsk2/dpZobNdG9IJbKF cu19zt4W+DKuLu3w+r3vT1M444iNA60lKN5mvgsdjxqTdzfhBMwmFwcF/lmkquvr7eA8 9/rW+3lMJXXR/Og75POmj5T+eVf8IEoth4TAX1Y4muf3apJWob80bnWUPW6hNsoV6dYe +BYKlZnermA2bImYSYQHoQli+aTCH5mKyTTHn9HXprWbceJVhnCychGReZQ/BnPPWXzU 1m7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704440006; x=1705044806; 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=aHicSr6rOWVvMTesmGW7ZwN5Nw8dTnXVRJbiDId9Yc8=; b=VG2LRoqvdMlQfEGhi0aFoDArbjJq3Y4WpHZonc7xceNzaFGVMwKuYzVRdsDoanc2Bv 16axmzmevkrfYOI6UtOhR11MSaI20lSweRzJgSSTlWTM7Qk7Sc7N65GkDTvipMfukHor CW0nFVTgAntMlRkMIFktuGwG7x5ejdi7Wh30Q3ROYQq/zJj/5K/0ft8ToWP8lZNx6foG eQ9gv/RvQRrnl0oYfsCl4r+1zSxd0Ltb0yc68diIq6+SFmopEFI4d1453ZeowVpVVFHY 8jAhgQvsr3FY+RnxvtgRHkKflH1PPAiZONyLFEvqQ6ZXCxmQesGp/dYpceBnIEG9QmEx 1deA== X-Gm-Message-State: AOJu0Ywe+aHPn/8siWhsZhRDWXZyljgVIAilgDp+rbDuDEMwvQ7iBVfp 6pVN5FkWjeFFJcGevTvS9IcKBru3a1/4iL9rck0= X-Google-Smtp-Source: AGHT+IEF8eNazSeWcZCLl5J4WikEWT2ApmNtS2OD3iw0mE1zKSuViISACLJ+zY7W88Oo6QnO5yCoRcVVwHxU7fNbT00= X-Received: by 2002:a05:651c:b2c:b0:2cd:1aa5:db82 with SMTP id b44-20020a05651c0b2c00b002cd1aa5db82mr979627ljr.21.1704440006026; Thu, 04 Jan 2024 23:33:26 -0800 (PST) MIME-Version: 1.0 References: <20240102175338.62012-1-ryncsn@gmail.com> <20240102175338.62012-5-ryncsn@gmail.com> <878r54b6ae.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <878r54b6ae.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Kairui Song Date: Fri, 5 Jan 2024 15:33:08 +0800 Message-ID: Subject: Re: [PATCH v2 4/9] mm/swap: always account swapped in page into current memcg To: "Huang, Ying" Cc: linux-mm@kvack.org, Andrew Morton , Chris Li , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , Yosry Ahmed , David Hildenbrand , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1FC511C0002 X-Stat-Signature: u4em5chuat9zwuz63i3ecucucdd59s1a X-HE-Tag: 1704440007-902399 X-HE-Meta: U2FsdGVkX1838xYn8WpY8fBq1trKTlyQuNkdTW3Oav5JLO7nJZFCBX7D/h/4MO0GZ+koNHFN5Rpma1MQIURU6YoRY4L9UlRqLrULeN0+zPWzOZw11YAaLXaJnc7pcgMJnFpurPjgB+1JmmjHK0wvkJjawHD4mEAtlcTcC3eyHeTD1wwPZ06S+7Oa1L7oKfqc/kc6IZKgxtUzCpCilHjY1O+BxW0uWu+Blgpb8XhnMI+L3MskG3B1QZgkdMR0Gi9pduWfGW0DWmS9yktkV3DBy3zo3yOl3hj8zuJWWY8tVHgW3Z6YGS2sLAKfvKL6xZLRgEipQ5A9Z6/LS1slYNPe5MvAiICGpjUW+twMn4p8QBQRSAT6LC4yDkVFE+lVsJAsxdkz3Ovwe6qPE9gU0Oe3suIiSF7YwECfzhC/E9tyYPIFwAsZZ5l9mAYM7m9AGc6EYCTAypoFxVMX3banVDsa38pKs0jDs3Xxj6cnVyPyIx2G+JIrir7H6A39qJPvhBkHDD8seCRyA2nq4SMsXqKtataw8b/KybtxyjnJQR8eBj8LhRkYANHcSQqpW/sGOqk5BjH14IR0D6yc1tJPBiHEO4RnCWHtS2NQsA0Wz6cud5VTUpniw1fJETbIxEOzf2hDdXEoSvEx6/qmX5PbNmvFy45nDrfcB0veIQO8CFyofq4Bz6VRFg0rspoLte0U71SQBwP80rCj9wt6q+kfNXLif74VZqiOgECCZHbvvac93bd/34O0c3gFZbFDka5jWzfOe08t2qTUG+pGtg31dWautATUwWUOJXr6meLG1PgANR5EngvKZQwvQQx3zqwSPbz9XStjDY4POl+enJGxLZexvVSd4KqKxE6dVBdGLFSzPFwoeGZ1gBa+AEWAobGkrpqrXiRPdrRORjm0vx5Pkmz6sG7yoid2YyhvmiXU3/IcWigcG02I/vrfENdkdZ1XoRneuSD9fbgjWVvohmF6eqB +gzsqbMq qE6pBw9kjaBnSuis/5zjqL18oUcuYcdAfcO4lWvuvzhmP3U0ciqvNM7V8eRVsCaWmd6V8oRCzWvnCX2ye2QVa8zK1WoSuwABYCVJL4uZZv+egVTxg1r+HBhsPnURGzDTxdVpWAYqfOdWPMAIEZN6jz2NWyvKfeuIYS3rdwQQyJRz4gitP368O6yXT3SIjEcJ4qd0zPU/4kHotTUL7JeDfE8wQSyXufc6Urdz5nK19T+TZP/FhKdGMvKbOv0MrwgrnJGn2u+2fP1SNy3qEykBaPwjLh4+eOttwf0TDUhy9KbVB4Z7pes4pdaqS0iFzeoC22axQcSokXwMPAF7fBGjyMAlHkR3K6s90vvnhbAUUPYm/eooT5+M5lM9C7Vr261RRDLsx9CvontEW7iXU8YvXUuwhYjoKHr0NudGPW7G00yckb04PIda4p/bAk6VxW+EuBwpG9edejw4wLgMOtcHC04G78fJE+GgRjn+bQwOshJJ7sEzl7W/ado+DRd0lEFd/+iGW9X6uQZGSoS+q6JOU16/kBcyVqK0RgwFD 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: List-Subscribe: List-Unsubscribe: Huang, Ying =E4=BA=8E2024=E5=B9=B41=E6=9C=885=E6=97= =A5=E5=91=A8=E4=BA=94 15:16=E5=86=99=E9=81=93=EF=BC=9A > > Kairui Song writes: > > > From: Kairui Song > > > > Currently, mem_cgroup_swapin_charge_folio is always called with > > mm argument as NULL, except in swapin_direct. > > > > swapin_direct is used when swapin should skip readahead and > > swapcache (SWP_SYNCHRONOUS_IO). Other caller paths of > > mem_cgroup_swapin_charge_folio are for swapin that should > > not skip readahead and cache. > > > > This could cause swapin charging to behave differently depending > > on swap device. This currently didn't happen because the only call > > path of swapin_direct is the direct anon page fault path, where mm > > equals to current->mm, but will no longer be true if swapin_direct > > is shared and have other callers (eg, swapoff). > > > > So make swapin_direct also passes NULL for mm, no feature change. > > > > Signed-off-by: Kairui Song > > --- > > mm/swap_state.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/swap_state.c b/mm/swap_state.c > > index 6130de8d5226..d39c5369da21 100644 > > --- a/mm/swap_state.c > > +++ b/mm/swap_state.c > > @@ -881,7 +881,7 @@ struct folio *swapin_direct(swp_entry_t entry, gfp_= t gfp_mask, > > folio =3D vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, > > vma, vmf->address, false); > > if (folio) { > > - if (mem_cgroup_swapin_charge_folio(folio, vma->vm_mm, > > + if (mem_cgroup_swapin_charge_folio(folio, NULL, > > GFP_KERNEL, entry)) { > > folio_put(folio); > > return NULL; > > I think that why not provide "mm" when it's available? For > swapin_direct() called by do_swap_page(), mm can be provided. While, > for swapin_direct() called by shmem swapin, mm will be NULL. We can > even provide "mm" for __read_swap_cache_async() for VMA based swapin and > for the fault address for cluster swapin. Hi, Ying. Thanks for the comment. Without modifying too much code, providing mm here will change swapin charge behaviour on swapoff, we discussed it previously: https://lkml.org/lkml/2023/11/19/320 If we want to avoid the behavior change, we have to extend all direct and indirect callers of mem_cgroup_swapin_charge_folio to accept a standalone mm argument (including swapin_direct, swap_vma_readahead, swap_cluster_readahead, __read_swap_cache_async, swapin_entry_mpol, read_swap_cache_async, and some other path may need more audit), and sort things our case by case. I'm not sure if that's a good idea... Simply dropping it here seems the easiest way to avoid such change.