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 B6EF1C3DA6E for ; Mon, 8 Jan 2024 07:46:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35DE26B0082; Mon, 8 Jan 2024 02:46:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 30DD46B0083; Mon, 8 Jan 2024 02:46:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D65E6B0085; Mon, 8 Jan 2024 02:46:22 -0500 (EST) 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 0E8736B0082 for ; Mon, 8 Jan 2024 02:46:22 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D1EDD12079B for ; Mon, 8 Jan 2024 07:46:21 +0000 (UTC) X-FDA: 81655360962.10.B2F1D73 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf02.hostedemail.com (Postfix) with ESMTP id D168B80005 for ; Mon, 8 Jan 2024 07:46:19 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="V54/i6u3"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704699980; 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=5uuf1WA3GMGAhZqdEbxPUoYJoKxkOOUO31g+e5SNclA=; b=TUyyEIeY4lhrEUigR73sYL+3iejQQ3BL1T/mXUPaoOGkX0Lj/9uPbs/7hnG2kWaKOK+IQ5 iskA+qvxmZXsIsm9bygQDa4mOFoICbnr1YD//IFnSMZWy3ngOy3vt0hOUmsNm1bDdoAfzh ujrsuiCrIWczI9cGbaj5D02hQiq+Q/A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="V54/i6u3"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704699980; a=rsa-sha256; cv=none; b=mgFSAeLRY8CXh1/t4Kf2rhEgjrnZz1HIpZLDEroREbeUUnKzA9+Ov28RZmhR4V7Kdwtvhv KOiF0ShTcvrztH7e8e1AEtAtruzLCf5MWupJcc7FpaRj4mpcVBY8H+bJtmrqi0kwl0Rqnx rkgEE78URqjJQr97Mc0exVxMTfRhMp4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704699980; x=1736235980; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=PZxQ8Ps+P7mZ0Hr0oqTsFUwxlBWxzQlbFso4pftin1o=; b=V54/i6u3RlaNZAaxAQ89gkmPGTwawh3PRCyN9sXTsOq09M4qw3hotZKe 1Ki6e3rK98pbzJxIX5ZJXwJZhKsKevROtvXrX2Iqpb8XhgmOL7q9BRR1N XgO98+ayQOXMBfQwSoT7W5kFJXw/tp6P+57A+ytS7ZU4KWetVN+DBGCTa pGIxq21Pw61MyIyw9VuS2gk99Iet3puRsdtogeABLOAuN0+xg1uSfC3jG 666xI0WQzcGgjBUNu8xQI3Li1M0GvaloXTr6qOvGfGUMKJU4UkYcau+Qr Kt4e0lQQK9nk+LtlXeY1cQLNtNbbVTtjHD0xOH96v7Ed1byx1Ftx7Wrw+ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10946"; a="5170478" X-IronPort-AV: E=Sophos;i="6.04,340,1695711600"; d="scan'208";a="5170478" 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) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: i5swcw93w5jf818tujsudnytnqyy3cgp X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D168B80005 X-HE-Tag: 1704699979-702043 X-HE-Meta: U2FsdGVkX1//CW/lRAJrvPj+o5hem7WT9eDp6MQOdibwh44you5n2Wv+k5PQOXSuPlFnUXbZq/zC8Gks0QpUC+Gw8lSraIer2AQ/l0tC/ubAwvzRud0IBIDa/xau/BEYfNH6dZlHAfcLA7VjZHkt1bTRBqkEeiCkqIqvimc4NvdsEeyx0nKZu1W0QvZuKXAvBnq3QPj6YU90VgOdkOpi8x4tbY9zBb4l35cihvo2PpT5LNuoJ1ingzk5z6Q8u86iXiqTJgudb9b5vn/RlwslUMPUIJ0zMyEGZLUEyhWc+HR9X4wU5c3vluwme5Ynz42hQBKZo/dUOenxPSmstcIF9CVpxW8AhO+/voxBHMYf9GR0rUAx2WPQWriYEeFLkaGqv1SrG5xUUFoHd91JWLmzFd/S2aehjyunCDgSyHnenKHFC+hdBd9AI7gdKG+0Vjm8BGsZlCO597O78H/9b5yEDG2AXMqXDDzTPs04za/rzuSeRf3URPQPmawy95iLiJZWFysLx5KpnawiStYi8s3EemstaxBSCzAuz6rvbO3dbddr+QXh7ZOGroZRISGRr39i4MoJzu3sRtnAGAxR5SGyvGWsxWJa5X7mkELeMv0e7AoI1avonHvsitaCY8NuXsVQFgX9mq5gE29rk7X1pAuMoYBWyXV5Jd+gy7YjRl98rJTjOHhB4cuMY0LjsBEqNVmJrHng2BK0V3VfJdeNievBLvxlaRAEo8OPynfAvZUteVQrU9uF1GF381JTUErdQyPr9Sb9hwK+ju5Zijc6bG7ImlU4kpTQkty2IjAV2MHNx4HHIA2rnruWB7IB9qA3jnlj+7wvgtgUGJadxcld5ZrurXE/3ziyTiXW+mn2J2TNfx+7GP9StXhZAKshyjIqIbQs92SFhxN2BImrgyLLVtLbW/qp0R2l+Vddma287FaAygYXhml/xCgtsiss1gCDhlZd3L8Z3EVxp8lDNE5ylmN Jp3Makfu APK9AUZfpOhRGWLcR0MCQ6XYaX82GntrxoMxusoTQRcu/xnWqSIG3/n4V7oVdYcYW/XrE7H14U72Pc1vhJQj2OHJz6ZFskRP/LjOK5vLFNJk1MkdqtZU6K7Gs1wYWJfH7obtIxRbEYcecfrjkBf2OD/NL+wHNtR1E4Lg49cArreIhQEHBfSvAbNA2tZsVYo7EiuNSSd41NBwcVpUjV2DLLjgzk9y31/StzhiStGSV8e01B3SIuI5aAiZEu/QImBdGOei7Qz4j0QXD9t2VBfbNBbHPWzRnvfzHTE4D3c1vwsorKATjw5cKzO/pyW2RfJEfIo88FpYDw8BKTmDoO04lb5unRFanw37wIJHlc3fgB43gSBqHZAt+vwvRDC1IyInh7qR+LTx3N1q4cnE/5iv85FWeepv/TGEDIzpj7/KBXBZuYQbDoClHTvhqm5ykm3ZdOKB6HRbSIleZN5ofBYb7rHvxp0JKnZVpd93F 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: 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