Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp1481962rdb; Sun, 7 Jan 2024 23:46:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IGVz85kOKrFr6Hv1/J53MqGRbiFOEh0BNQH8Xqjwu9CBgpXCeKujVIdLvnFspplAgqOKRBz X-Received: by 2002:a05:620a:2a09:b0:781:7239:ae4e with SMTP id o9-20020a05620a2a0900b007817239ae4emr4422365qkp.79.1704699992804; Sun, 07 Jan 2024 23:46:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704699992; cv=none; d=google.com; s=arc-20160816; b=hLBLvPjJ/E/hI/oPjYvMmudTRFd2u8d8zxXo2IjIK9BnDrszwxX6o3g3+Bf/LcVVTv jW6tTOr9l1lIsAGB+WiHPd4IWp5ZKud2PSwfcrP4CXQLgDUk4sikgWIXbZdxXIgR2lLs m67MHTc4Li65Yi18w5AgHzgx+9IhT/24kbkCeWtFABhGqsvs89ua7v67QnQ7WyI4YGtn emjuNAM7YnuRsYQ2CzK5hkBiEBMXkDqbCxCssgENhgXUExRM1O4LF1RMHa//zhdaHmye ApOp4p1xshP2qOZMZSKZ8XIBVluHDtnArRqat/lVaU3XVznrD+ChMVx8MitU5T2o1xpk GxzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=5uuf1WA3GMGAhZqdEbxPUoYJoKxkOOUO31g+e5SNclA=; fh=7noh5WZaNqfyWTHOXpEdI8kSahCokXsI29EKqpOErr0=; b=wZMCf0sEmBltrBWzfzP3irxETwWiDE/SrTFVUSYmgNa9DArKmiY3NWA+NyazWGECSd JXREwTGUQ3jGFBNdqTdsAapFnxUDCkpQ32uwmRQApazYpVpV7k1Sp60wum7VDit8fXKw wYLvvx2GAXdMkxCbvMzw2nrLaGVG3Mi2DDkyPirz0ewjAOLE1Acg6r6vdObjl67p3tqI szaCo2ES1HC07gdoc2TYtXqyD3sdKJ/1gDBiHtOryL1FqeUmVjlglvMIuxoX7YCdS+p6 MxktEppbP49vDwLu6TivntnK1gi1OMJ7I0Cv9QnMS3zHwbfagOLa+FEne2EuQclqWcjo ocGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bxEAxt3W; spf=pass (google.com: domain of linux-kernel+bounces-19153-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19153-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id bk13-20020a05620a1a0d00b0078323bbd24esi1453955qkb.352.2024.01.07.23.46.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jan 2024 23:46:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19153-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bxEAxt3W; spf=pass (google.com: domain of linux-kernel+bounces-19153-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19153-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 8AD7C1C21A15 for ; Mon, 8 Jan 2024 07:46:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 25FA88C17; Mon, 8 Jan 2024 07:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="bxEAxt3W" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A45DAE578 for ; Mon, 8 Jan 2024 07:46:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704699979; x=1736235979; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=PZxQ8Ps+P7mZ0Hr0oqTsFUwxlBWxzQlbFso4pftin1o=; b=bxEAxt3WL4w9REKuZKvJ/I7senPjn4R+kJKA3LMOfuIttjyEMyDXiODC pY6GB5vjrzRCKTprHkf3mdkk21JJU5DwLg/CnC5Ed4q79SlEKO7S4HcTV R9NEIMD1HqKNlSfTKPolJ2ESLWIZ1z2ZF0HdClI7tzQieDmzyztXGQcfY pB5OnEs8LwyXa8g+A3hntrc1DIZekwZnCw7M4fZDU85S/tHqZ3ukbMxgU 8YawFuDXatDvO28aTJ3l6aF75AsBo8HtDRDo7yfYRh37uM8trF4GpDLmy Bojqf4tLdJ+tnXA1tTXWxciNwT+auYLjkAvCtFouOo7bOvKy3SXF6FGbj w==; X-IronPort-AV: E=McAfee;i="6600,9927,10946"; a="5170477" X-IronPort-AV: E=Sophos;i="6.04,340,1695711600"; d="scan'208";a="5170477" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2024 23:46:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10946"; a="900294546" X-IronPort-AV: E=Sophos;i="6.04,340,1695711600"; d="scan'208";a="900294546" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jan 2024 23:46:14 -0800 From: "Huang, Ying" To: Kairui Song 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 Subject: Re: [PATCH v2 4/9] mm/swap: always account swapped in page into current memcg In-Reply-To: (Kairui Song's message of "Fri, 5 Jan 2024 15:33:08 +0800") References: <20240102175338.62012-1-ryncsn@gmail.com> <20240102175338.62012-5-ryncsn@gmail.com> <878r54b6ae.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 08 Jan 2024 15:44:17 +0800 Message-ID: <87edes9smm.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kairui Song writes: > 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 It's better to use "lore" for kernel email link, for example, https://lore.kernel.org/lkml/20231119194740.94101-24-ryncsn@gmail.com/ This is more readable than the above link. > 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. OK. Didn't realize that they are related directly. It appears that we always pass NULL as mm to mem_cgroup_swapin_charge_folio(). If so, please just remove the parameter. -- Best Regards, Huang, Ying