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 9E70FC25B78 for ; Thu, 23 May 2024 02:32:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFC7B6B0093; Wed, 22 May 2024 22:32:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAC6A6B0095; Wed, 22 May 2024 22:32:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9B886B0096; Wed, 22 May 2024 22:32:02 -0400 (EDT) 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 BD0416B0093 for ; Wed, 22 May 2024 22:32:02 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 69F95801A9 for ; Thu, 23 May 2024 02:32:02 +0000 (UTC) X-FDA: 82148085684.13.7B3D97F Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf25.hostedemail.com (Postfix) with ESMTP id C5B9EA0002 for ; Thu, 23 May 2024 02:31:58 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="O/Tz7Oy5"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716431520; 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=ack/kVE3TxqOGngSexMdxdtp5NY2ZX4sfLT+4hAq/lQ=; b=t59c5DBoWiXNVEW0C5OhS5aERdltNnDYF33zx1uFbiqvDUy61BsS5dMvnESj9tK7vg23ox eDf9erVpRWKEFdM0ceCSdIkalK9utVJe5qkTJzTdJ8pQ2jRYLl5b6Q0dJvRrnwT0kC23tO dTJ/hCx6IZro7QmMObsIyplk0H+H07Y= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b="O/Tz7Oy5"; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716431520; a=rsa-sha256; cv=none; b=sDKDgy04Bum8dmtgv7tMuUR7wYh2amxfRNfsNXn+kxlW5g1xu4G2dvT83Mjj6gtBUKUxbP Ql+v99N/naTErfpVVLiXM3Lf08/cdb679dpqxRwCab8Qob1LMqVPJLj+0n6FD5iwPbjlR2 5S9GITOBHFqnosJj/VRsNtQfnjhOXTc= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1716431516; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ack/kVE3TxqOGngSexMdxdtp5NY2ZX4sfLT+4hAq/lQ=; b=O/Tz7Oy5Lk8krItAv4XF42D5hWYe9OkgQaE/PZN0hjodZk/Bnj1tQmzuJ1I1VXvIqvPaLb7efz4HEjdwlVl5c/r/Uljwdd0MqDR6gmZdGNLjD3CgJIlRwvjrS8uW7nt+XOIPzmG+pq/Pziit1esrcUcaWK6FSrbe8ON3fR0zCCs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045075189;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0W718O2a_1716431513; Received: from 30.97.56.57(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W718O2a_1716431513) by smtp.aliyun-inc.com; Thu, 23 May 2024 10:31:54 +0800 Message-ID: <2ee94722-456f-4db0-9ed9-3f1c72239a75@linux.alibaba.com> Date: Thu, 23 May 2024 10:31:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: drop the 'anon_' prefix for swap-out mTHP counters To: Barry Song <21cnbao@gmail.com> Cc: "Huang, Ying" , David Hildenbrand , akpm@linux-foundation.org, willy@infradead.org, ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <0e2a6f232e7579a2e4407ecf075531980d97f286.1716367360.git.baolin.wang@linux.alibaba.com> <22ac01a3-ddbb-4114-88cd-ad1a31982dad@redhat.com> <51ba1fc1-fd77-4601-8d27-459162fd008c@linux.alibaba.com> <875xv5ba8t.fsf@yhuang6-desk2.ccr.corp.intel.com> <18aa865a-6d4a-4dcf-99ce-bcfbc0c92f19@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C5B9EA0002 X-Stat-Signature: wnss6p5kuaq9esqzrrkbde67hde3k854 X-HE-Tag: 1716431518-265008 X-HE-Meta: U2FsdGVkX1+RbKvzmflyQCRklEKuhvAY7J/DhdFwqEXT/wagwPUBHoufiY+XFHjAc95XQ/wuZzcaj/t9ZKuFwaikXvk6MCekiyOKcqN69pRDvYhK3da+F+n/v7kQEmYAjr7X3In2SihR2NlmrZCjvQOp2RpW/xFoJ/HLHQOBpPNFgEmZT54G56xvvLL1lu2Xp+GH0dYsKj3IniUMWchVg+O0jS34TGYNCmfqGWME0tk/Cs5v1qlUJIdDhetrbSlTFcYKNnbmFpnc+n5TpgykO5KtbylHF89UEYmGXfdNCqywN5uf6J6HBMUQMSAjkeVmHnSDvO8LLyIA7bKpImls5R6lPj3sqCrAVycPl2O/fnU3u2zW7VnBKZFDWbad+U5VGbC1QmTq2VWffmXujVQk/lqZbydSahsGccs84IoIgu7OVgFislCeZzQ4rnGM24ZDfaQIAuNr02CNwipRQlhpudxRC1FdkQEMpRzkw81nfdIZfgVlojKi8pFBwFsg3ccGQ8ZQlzGm8ZzxTCnumLh0Eo8Bg2VNAv6WZTb5tzwAZ6zmRyJK6nimGvP0ACP8eMTA3pe2kL7cg6u5Tp8DuOuQg0e9Tra9qFaf3ITiyMsyqKt9+fCgKEPinTuq3P6/RgeCeMjavfloD2VHzaLim3KakBDchzRKFMwgyIZ1xxIO+aGrIWaz0sLwC+6TcWe1zpZJJzyM5b2wP+2Iv2o1ffsJgixw6VfBJ7mX1Pi/pdh7GJbhiTvDIdRF2yrmbRmFXfYsBt44St0cfYT1xKz5rFkFHRE1KDqIMNG1UQb9/BnFuDKUOoHzJG138Z5VpbYnA86CLmaT+KwXktoy2CSHXCtqn+ALRl+ArnSPFADapxT+kXE1LqT+UQTR38fIPvjljgQ4be58Pyj+hjZeD/8LGEAUb9kagIk5zySvzofsQR75hwre2CfEfuE8J0onksc49dvBVT6fL3IUMioNccZsBrs x2EA0pfF kODLlHGvqGJO+KTYkpDtfYPeRN+6TfDXOvmz0EzqRw2i2XDESFxqGUZA9n7D89tpV7HowAN2/mCev1LvrsEsgT/ybCxvnc7AskDXki6HMj/8KFiQ85y2uo2cg6cye4hY/RpBWvqwB45hPEgoyRvNsTUQL6tav2z4zKnrOt6i2gA1+rje2IHnCArCywaZzcKeOmsHXj8hq7I8SpuevnApeVTYQyDMbGaFFN+3x2y3cAr5ff6cgtYz/GlzL9Rrbpj+ep6qv7DGc6jBUkbvEJAbctYzOIYZGYNwO5XC3z/LNHJB9jerfoZYW6eEx/3DZvPyN8aVK7x/RcajmG4fwKC6B/pO5+TJ+KAe/uiQQeHhLCCbX/O1u6Urx8HeW2BGFykzctrXYf1MCOCTGYtZ8+6ccHditQpt5/VAMq9RJPWNLo0i+WDvWSkjsOKw4CmbitTLMliPBvDq+5QNIejyPsPDbcLbSGJ5z1v1jGbNNLvYWRiOAYeryv/7c7O4KgVNptaThzTkdrm+HVlJOWUhmvJvdeJ1m+MsBls6l5frYiIQ2qp3HTIA= 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: On 2024/5/23 10:12, Barry Song wrote: > On Thu, May 23, 2024 at 1:38 PM Baolin Wang > wrote: >> >> >> >> On 2024/5/23 09:14, Huang, Ying wrote: >>> Barry Song <21cnbao@gmail.com> writes: >>> >>>> On Wed, May 22, 2024 at 9:38 PM Baolin Wang >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 2024/5/22 16:58, David Hildenbrand wrote: >>>>>> On 22.05.24 10:51, Baolin Wang wrote: >>>>>>> The mTHP swap related counters: 'anon_swpout' and >>>>>>> 'anon_swpout_fallback' are >>>>>>> confusing with an 'anon_' prefix, since the shmem can swap out >>>>>>> non-anonymous >>>>>>> pages. So drop the 'anon_' prefix to keep consistent with the old swap >>>>>>> counter >>>>>>> names. >>>>>>> >>>>>>> Suggested-by: "Huang, Ying" >>>>>>> Signed-off-by: Baolin Wang >>>>>>> --- >>>>>> >>>>>> Am I daydreaming or did we add the anon_ for a reason and discussed the >>>>>> interaction with shmem? At least I remember some discussion around that. >>>>> >>>>> Do you mean the shmem mTHP allocation counters in previous >>>>> discussion[1]? But for 'anon_swpout' and 'anon_swpout_fallback', I can >>>>> not find previous discussions that provided a reason for adding the >>>>> ‘anon_’ prefix. Barry, any comments? Thanks. >>>> >>>> HI Baolin, >>>> We had tons of emails discussing about namin and I found this email, >>>> >>>> https://lore.kernel.org/all/bca6d142-15fd-4af5-9f71-821f891e8305@redhat.com/ >>>> >>>> David had this comment, >>>> "I'm wondering if these should be ANON specific for now. We might want to >>>> add others (shmem, file) in the future." >>>> >>>> This is likely how the 'anon_' prefix started being added, although it >>>> wasn't specifically >>>> targeting swapout. >>>> >>>> I sense your patch slightly alters the behavior of thp_swpout_fallback >>>> in /proc/vmstat. >>>> Previously, we didn't classify them as THP_SWPOUT_FALLBACK, even though we >>>> always split them. >>> >>> IIUC, "fallback" means you try to do something, but fail, so try >>> something else as fallback. If so, then we don't need to count >>> splitting shmem large folio as fallback. >> >> Agree. In additon, IIUC we have never counted splitting shmem large >> folio as THP_SWPOUT_FALLBACK before or after this patch. > > Hi Baolin, > > My point is that THP_SWPOUT* has been dedicated to anonymous memory for years > because we have not had the capability to perform THP_SWPOUT for shared memory > before. This is the historical context of thp_swpout* in /proc/vmstat, > even though it is > not ideal. Therefore, placing shmem sysfs entries in > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/stats > allows us to monitor SWPOUT and SWPOUT FALLBACK for shmem without altering > the tradition of /proc/vmstat. OK, I see your point. IMO this patch will not change the behaviors of thp_swpout* in /proc/vmstat until adding support for large folio swap-out for shmem[1]. Anyway we can talk about this in that thread. [1] https://lore.kernel.org/all/cover.1716285099.git.baolin.wang@linux.alibaba.com/ > But I am not firm on this because I don't see the necessity to > differentiate shmem's > swpout from anon's swpout. They basically seem the same while anon mTHP > faults might be significantly different from file mTHP faults, in which case we > must distinguish them. So please send version 2 with the updated documentation. > I believe it should target v6.10-rc rather than v6.11 to avoid ABI > conflicts if it is > accepted. Sure. Will do. Thanks.