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 7CE26C2BD09 for ; Tue, 9 Jul 2024 08:40:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12FDE6B0099; Tue, 9 Jul 2024 04:40:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E0876B009D; Tue, 9 Jul 2024 04:40:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC2AA6B009E; Tue, 9 Jul 2024 04:40:48 -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 C92CD6B0099 for ; Tue, 9 Jul 2024 04:40:48 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5187F1A1760 for ; Tue, 9 Jul 2024 08:40:48 +0000 (UTC) X-FDA: 82319568576.23.65E0152 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf25.hostedemail.com (Postfix) with ESMTP id 89844A0002 for ; Tue, 9 Jul 2024 08:40:46 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q9ZLRkl8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720514423; a=rsa-sha256; cv=none; b=u0bhaJ7VkChLbs/vx4uV9swkNI3NNeOeUJRhEkpGUbv+uJY3UXiN0PvM2g5fs8zyNwU7ag emJrQsKgyFD3reP6M6CUvh/HnBLJRmxIzH2eMzN6ZnuDnImMCOmKZxIAWSpJVoCi+xyBk+ 1wghwdnKfQSq3WK0GB+KE5yX0rQHeQU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q9ZLRkl8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720514423; 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=Wkf5PEVVroZQU0ibXyGfvUtBNP42hby94wuGeZsbdJI=; b=E5KVzpAUX3lrOgM+38Imb9ZGDn0DedvjseVI9g0fm0c8awxKUxFDfuAZJ/C1RKy4YEU5z/ b6QvOpC2W38QJarU9/QIsnIGEawQzrxxskSbTPei5O0nsId9dA6/kw3XtOLA7XgCeKRDG2 m0PrVJ5H0Sa1dp/ER7rMMfQYh4WwY+A= Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4f2da6cbe7bso1646392e0c.2 for ; Tue, 09 Jul 2024 01:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720514445; x=1721119245; 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=Wkf5PEVVroZQU0ibXyGfvUtBNP42hby94wuGeZsbdJI=; b=Q9ZLRkl8jM1OtZM4s1VjcMxWXsLI2W4HpdvRQx1nLWZendhQn+eyNmM3PqDnDauiYs V31td/MOIGce1Hc2YSK5TSy1vhksdyvrUYRVVY0GdHpTYQKmTCwUF/D7ElqGpu84ZG0f BbUBLEPX7AFLb3sRb0I8cF+7mJkLanSzof0CehJd/fitgRHxnP+9/hXtd3zq5lAURLSC XoyjRR5LbRVFcLS0l+E68HAUwRw6ySl22gPPNWPYB7bE2pwMpwGf6JxudmvGMTmfJfsX MeM7WWaG0rVHXV6F0XSbGLeChsZgOAoPl6cXWZ983vtb2hAWqYnXPZOEwJA8eRmnPisk sqLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720514445; x=1721119245; 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=Wkf5PEVVroZQU0ibXyGfvUtBNP42hby94wuGeZsbdJI=; b=NkOxhpEJ6PCPdN/lmqUOpXi73all9b1a7HyM7jgkasLVZej04fuqfqV/H1BDg0jYJr wTRvZG5HrsjMn7hwG2hyGfUMPV4QE6Y7dOjRIPBB1d6n274bd7CL4NFsIe2DSraYZAQZ BbSGoCTc8oGKsPHSnsEPx1rdahHL/9TTyfmwfNTIT8l3onfHTfsAVStcngF6kMbzcisw DAqa5gSz+XQQzTbov7X/Ss0wthUNG6oOuEzBgHv5vTetBJLq1299DEv238AwJPi+JLBp 2dMBrGr97xNSzc859qUUXqtMf1Z775g0U2bmLaLSWVl4tQrwgI+GTKNVRRjOe+TdJfwc PCgg== X-Forwarded-Encrypted: i=1; AJvYcCVKRd51lf5ILf4DAJ63OAgnPr0PQWzGWhc8+o6AA5AHzb4pKyUZYDzhI1tsC2iVLHW8UQhnZuAAu+t7kVoNgS/JN/Y= X-Gm-Message-State: AOJu0YxArQlyC0OB9g7ZnjpkDI6b75Hk6dfnPEFe018zAYqroPeqe/rg mqDA9HkEQRodbapona6+7+IIYtBUkbAA0fqPNLDB66W6hfIlSa8JBeBscm8CpLbLxeO2iTGlS5F qNOibh+3OCXibgp6ep45xgoCyWr6sQAy3 X-Google-Smtp-Source: AGHT+IER5vkOK60vv6XIdWIjwHRWJBQA/EhroFdyPhSSlIy1AfhdGNlsYTeFuCt45vUBeMHALngq0jYU27SITCjg3Eo= X-Received: by 2002:a05:6122:1350:b0:4f2:ffa9:78b5 with SMTP id 71dfb90a1353d-4f33f2f7b89mr2189231e0c.11.1720514445409; Tue, 09 Jul 2024 01:40:45 -0700 (PDT) MIME-Version: 1.0 References: <744749c3-4506-40d9-ac48-0dbc59689f92@arm.com> <20240709014413.18044-1-21cnbao@gmail.com> <70ac8a5d-f6cf-41e6-b295-cd40b81fa85e@arm.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 9 Jul 2024 20:40:33 +1200 Message-ID: Subject: Re: [PATCH v1] mm: shmem: Rename mTHP shmem counters To: Ryan Roberts Cc: akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, corbet@lwn.net, da.gomez@samsung.com, david@redhat.com, hughd@google.com, ioworker0@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, ziy@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 89844A0002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: tqqwjy65gc8h1inkhcmfpu54c6irrgg3 X-HE-Tag: 1720514446-155076 X-HE-Meta: U2FsdGVkX18+AoRblyZVGOxakMrqfJlrBYsa6IPGoJGnAbB7tkPg9i4+VA73RJ5JytEQ0VEa3UUy3FK2GFswoMq672OHMzTWgulycPwyZOtm4QZIhvh6ZziAEke+10XCoUvS3hYn0wGgIo+TG2LClnNbOsNTGpWZnGUnkCz9rd6m38m9t0fX7NcoB1BzkxFRZeuraOLGrFiug5k4W6fN0Tcm5d+XGTg8TmNXSzUvnuWPbp3JyKM8hI7oih/uxqBuKnLzHaKGXHDh8x1ggucjjRhJmENeiD1m7t+aM7OWhYCa2RnU7UyaaipWwcCblnjAkPNfoEu27X9IvD8WzM6vPUkMK3YRXQdkifxSvWWf3rGQN+toG5BMEsQmvEzzYMLvpgpq2uN4JaptrwVUrspqSOEBoCJT7ify1UPgywTGE4+3zhKpSTGDYAekKalP/gz4mzqx5+4XILz+nLEYIUiuQ++OdQT3gukD6O1hE/KV9CahIlU8IOtl1mEkZSv2R9JgqsFgKkCXZBV7Bcyc0XDJyLQsz2QGP7rMDwCgm3M8zReIzhrO8nnl0BDivX+cIiFajD9D7h1cyIeaDx/tocg6hXTZwMEYmYOG7jh2GdkU1vEiHpr0GTSMcmtA2gqA0ipP3GMECSVPdCx+YnGKFIEaj+1H1d8ZEMS0Mg06q/2YR8tmxQ+lk7OzFoQjfUY944U9j1BKt7CvjXMvG4vIDRtNVVkpyfiqhmQMmtrnc3xG7OQGUzS1zj42X4wZfr65vwUlq/oQYKczB708cXsJWbZ7WIajOs+2lGC0+SCPthpNJpUMTzwHt8VvToj3yrpHX31gyRGyfHNCx93brjalC0PxuCI+MXzC8nQQSnwOP6rh8QuxVPOUR/RELm1LxXtPCLr/KHt/PH+6DiGHVQPc91kajpD0Se+0VT6tLprv+3B8/ULCbwCQnPiklWAQ8uYcPuZkvstYQT14j/ZUhKo2/UG XfSlm+ec V0Rcjc85OUTg6+wvlzAPtWtjKpGbkSIFwvz8/RdIG+XsHwQz5Ug723MxHJD2LwLDvWT4i10q3OnvcGeq5VUPdcpTBVFRgtj+S4QrZAWvhkiKz6c53yKpvh7Hs+bub/kjRq+5XJ2b1pthXL7/WxnnzLfuueRUy4obRx4qKjRlI38pgAQTOSpdtDskjNOaDROQqKIaeS+0rXlRno8YZJzmZ/UUyXpYbr0kMuhPddhgMiCx55GjcEsPHds06Rn1ptuKGG0ZK+qzN+/pU4Mbn5I3PrZaVytVvYDHbtoShoPwGp/TlMk5V5WqHWNIypRGP4EfmTzNxKYUM4DQR/7i86qOptvzvuME4MhLpfPSjbnQiKsQ9AJ2B8QHiGhaQ4UnOdKEPbD3d+VvGrGQtuHCZWJhuKnSM80HRqjvIAbU9a7/yUZ5qS0ScSoKoVtBJFzBXR+pds1wl 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 Tue, Jul 9, 2024 at 8:35=E2=80=AFPM Ryan Roberts = wrote: > > On 09/07/2024 09:13, Barry Song wrote: > > On Tue, Jul 9, 2024 at 7:55=E2=80=AFPM Ryan Roberts wrote: > >> > >> On 09/07/2024 02:44, Barry Song wrote: > >>> On Tue, Jul 9, 2024 at 12:30=E2=80=AFAM Ryan Roberts wrote: > >>>> > >>>> On 08/07/2024 12:36, Barry Song wrote: > >>>>> On Mon, Jul 8, 2024 at 11:24=E2=80=AFPM Ryan Roberts wrote: > >>>>>> > >>>>>> The legacy PMD-sized THP counters at /proc/vmstat include > >>>>>> thp_file_alloc, thp_file_fallback and thp_file_fallback_charge, wh= ich > >>>>>> rather confusingly refer to shmem THP and do not include any other= types > >>>>>> of file pages. This is inconsistent since in most other places in = the > >>>>>> kernel, THP counters are explicitly separated for anon, shmem and = file > >>>>>> flavours. However, we are stuck with it since it constitutes a use= r ABI. > >>>>>> > >>>>>> Recently, commit 66f44583f9b6 ("mm: shmem: add mTHP counters for > >>>>>> anonymous shmem") added equivalent mTHP stats for shmem, keeping t= he > >>>>>> same "file_" prefix in the names. But in future, we may want to ad= d > >>>>>> extra stats to cover actual file pages, at which point, it would a= ll > >>>>>> become very confusing. > >>>>>> > >>>>>> So let's take the opportunity to rename these new counters "shmem_= " > >>>>>> before the change makes it upstream and the ABI becomes immutable. > >>>>> > >>>>> Personally, I think this approach is much clearer. However, I recal= l > >>>>> we discussed this > >>>>> before [1], and it seems that inconsistency is a concern? > >>>> > >>>> Embarrassingly, I don't recall that converstation at all :-| but at = least what I > >>>> said then is consistent with what I've done in this patch. > >>>> > >>>> I think David's conclusion from that thread was to call them FILE_, = and add both > >>>> shmem and pagecache counts to those counters, meaning we can keep th= e same name > >>>> as legacy THP counters. But those legacy THP counters only count shm= em, and I > >>>> don't think we would get away with adding pagecache counts to those = at this > >>>> point? (argument: they have been around for long time and there is a= risk that > >>>> user space relies on them and if they were to dramatically increase = due to > >>>> pagecache addition now that could break things). In that case, there= is still > >>>> inconsistency, but its worse; the names are consistent but the seman= tics are > >>>> inconsistent. > >>>> > >>>> So my vote is to change to SHMEM_ as per this patch :) > >>> > >>> I have no objections. However, I dislike the documentation for > >>> thp_file_*. Perhaps we can clean it all up together ? > >> > >> I agree that we should clean this documentation up and I'm happy to ro= ll it into > >> v2. However, I don't think what you have suggested is quite right. > >> > >> thp_file_alloc, thp_file_fallback and thp_file_fallback_charge *only* = count > >> shmem. They don't count pagecache. So perhaps the change should be "..= .every > >> time a shmem huge page (dispite being named after "file", the counter = measures > >> only shmem) is..."? > > > > I understand what you are saying, and I know that thp_file_* has only > > included shmem so far. My question is whether it will include regular > > files in the future? If not, I am perfectly fine with your approach. > > My whole reasoning for this patch is based on the assertion that since > THP_FILE_ALLOC has been there for 8 years and in all that time has only c= ounted > shmem, then its highly likely that someone is depending on that semantic = and we > can't change it. I don't have any actual evidence of code that relies on = it though. > > I propose I change the docs to reflect what's actually happening today (i= .e. > shmem *only*). If we later decide we want to also report page cache numbe= rs > through that same counter, then we can change the docs at that point. But= if I > get my way, we'll soon have mTHP counters for FILE, which is solely for p= age > cache. So You'll be able to get all the fine-grained info out of those an= d there > will be no need to mess with the legacy counters. Make sense to me. I'd rather we go to /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/stats/file_* /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/stats/shmem_* if we later have 2MiB file counters. > > > > > READ_ONLY_THP_FOR_FS isn't applicable in this path as it is created > > by khugepaged collapse. > > > >> > >> thp_file_mapped includes both file and shmem, so agree with your chang= e there. > >> > >> What do you think? > >> > >> > >>> > >>> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentati= on/admin-guide/mm/transhuge.rst > >>> index 709fe10b60f4..65df48cb3bbb 100644 > >>> --- a/Documentation/admin-guide/mm/transhuge.rst > >>> +++ b/Documentation/admin-guide/mm/transhuge.rst > >>> @@ -417,21 +417,22 @@ thp_collapse_alloc_failed > >>> the allocation. > >>> > >>> thp_file_alloc > >>> - is incremented every time a file huge page is successfully > >>> - allocated. > >>> + is incremented every time a file (including shmem) huge page is > >>> + successfully allocated. > >>> > >>> thp_file_fallback > >>> - is incremented if a file huge page is attempted to be allocated > >>> - but fails and instead falls back to using small pages. > >>> + is incremented if a file (including shmem) huge page is attempt= ed > >>> + to be allocated but fails and instead falls back to using small > >>> + pages. > >>> > >>> thp_file_fallback_charge > >>> - is incremented if a file huge page cannot be charged and instea= d > >>> - falls back to using small pages even though the allocation was > >>> - successful. > >>> + is incremented if a file (including shmem) huge page cannot be > >>> + charged and instead falls back to using small pages even though > >>> + the allocation was successful. > >>> > >>> thp_file_mapped > >>> - is incremented every time a file huge page is mapped into > >>> - user address space. > >>> + is incremented every time a file (including shmem) huge page is > >>> + mapped into user address space. > >>> > >>> thp_split_page > >>> is incremented every time a huge page is split into base > >>> > >>>> > >>>>> > >>>>> [1] https://lore.kernel.org/linux-mm/05d0096e4ec3e572d1d52d33a31a66= 1321ac1551.1713755580.git.baolin.wang@linux.alibaba.com/ > >>>>> > >>>>> > >>>>>> > >>>>>> Signed-off-by: Ryan Roberts > >>>>>> --- > >>>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> Applies on top of today's mm-unstable (2073cda629a4) and tested wi= th mm > >>>>>> selftests; no regressions observed. > >>>>>> > >>>>>> The backstory here is that I'd like to introduce some counters for= regular file > >>>>>> folio allocations to observe how often large folio allocation succ= eeds, but > >>>>>> these shmem counters are named "file" which is going to make thing= s confusing. > >>>>>> So hoping to solve that before commit 66f44583f9b6 ("mm: shmem: ad= d mTHP > >>>>>> counters for anonymous shmem") goes upstream (it is currently in m= m-stable). > >>>>>> > >>>>>> Admittedly, this change means the mTHP stat names are not the same= as the legacy > >>>>>> PMD-size THP names, but I think that's a smaller issue than having= "file_" mTHP > >>>>>> stats that only count shmem, then having to introduce "file2_" or = "pgcache_" > >>>>>> stats for the regular file memory, which is even more inconsistent= IMHO. I guess > >>>>>> the alternative is to count both shmem and file in these mTHP stat= s (that's how > >>>>>> they were documented anyway) but I think it's better to be able to= consider them > >>>>>> separately like we do for all the other counters. > >>>>>> > >>>>>> Thanks, > >>>>>> Ryan > >>>>>> > >>>>>> Documentation/admin-guide/mm/transhuge.rst | 12 ++++++------ > >>>>>> include/linux/huge_mm.h | 6 +++--- > >>>>>> mm/huge_memory.c | 12 ++++++------ > >>>>>> mm/shmem.c | 8 ++++---- > >>>>>> 4 files changed, 19 insertions(+), 19 deletions(-) > >>>>>> > >>>>>> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Document= ation/admin-guide/mm/transhuge.rst > >>>>>> index 747c811ee8f1..8b891689fc13 100644 > >>>>>> --- a/Documentation/admin-guide/mm/transhuge.rst > >>>>>> +++ b/Documentation/admin-guide/mm/transhuge.rst > >>>>>> @@ -496,16 +496,16 @@ swpout_fallback > >>>>>> Usually because failed to allocate some continuous swap sp= ace > >>>>>> for the huge page. > >>>>>> > >>>>>> -file_alloc > >>>>>> - is incremented every time a file huge page is successfully > >>>>>> +shmem_alloc > >>>>>> + is incremented every time a shmem huge page is successfull= y > >>>>>> allocated. > >>>>>> > >>>>>> -file_fallback > >>>>>> - is incremented if a file huge page is attempted to be allo= cated > >>>>>> +shmem_fallback > >>>>>> + is incremented if a shmem huge page is attempted to be all= ocated > >>>>>> but fails and instead falls back to using small pages. > >>>>>> > >>>>>> -file_fallback_charge > >>>>>> - is incremented if a file huge page cannot be charged and i= nstead > >>>>>> +shmem_fallback_charge > >>>>>> + is incremented if a shmem huge page cannot be charged and = instead > >>>>>> falls back to using small pages even though the allocation= was > >>>>>> successful. > >>>>>> > >>>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > >>>>>> index acb6ac24a07e..cff002be83eb 100644 > >>>>>> --- a/include/linux/huge_mm.h > >>>>>> +++ b/include/linux/huge_mm.h > >>>>>> @@ -269,9 +269,9 @@ enum mthp_stat_item { > >>>>>> MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE, > >>>>>> MTHP_STAT_SWPOUT, > >>>>>> MTHP_STAT_SWPOUT_FALLBACK, > >>>>>> - MTHP_STAT_FILE_ALLOC, > >>>>>> - MTHP_STAT_FILE_FALLBACK, > >>>>>> - MTHP_STAT_FILE_FALLBACK_CHARGE, > >>>>>> + MTHP_STAT_SHMEM_ALLOC, > >>>>>> + MTHP_STAT_SHMEM_FALLBACK, > >>>>>> + MTHP_STAT_SHMEM_FALLBACK_CHARGE, > >>>>>> MTHP_STAT_SPLIT, > >>>>>> MTHP_STAT_SPLIT_FAILED, > >>>>>> MTHP_STAT_SPLIT_DEFERRED, > >>>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c > >>>>>> index 9ec64aa2be94..f9696c94e211 100644 > >>>>>> --- a/mm/huge_memory.c > >>>>>> +++ b/mm/huge_memory.c > >>>>>> @@ -568,9 +568,9 @@ DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTH= P_STAT_ANON_FAULT_FALLBACK); > >>>>>> DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_= FAULT_FALLBACK_CHARGE); > >>>>>> DEFINE_MTHP_STAT_ATTR(swpout, MTHP_STAT_SWPOUT); > >>>>>> DEFINE_MTHP_STAT_ATTR(swpout_fallback, MTHP_STAT_SWPOUT_FALLBACK)= ; > >>>>>> -DEFINE_MTHP_STAT_ATTR(file_alloc, MTHP_STAT_FILE_ALLOC); > >>>>>> -DEFINE_MTHP_STAT_ATTR(file_fallback, MTHP_STAT_FILE_FALLBACK); > >>>>>> -DEFINE_MTHP_STAT_ATTR(file_fallback_charge, MTHP_STAT_FILE_FALLBA= CK_CHARGE); > >>>>>> +DEFINE_MTHP_STAT_ATTR(shmem_alloc, MTHP_STAT_SHMEM_ALLOC); > >>>>>> +DEFINE_MTHP_STAT_ATTR(shmem_fallback, MTHP_STAT_SHMEM_FALLBACK); > >>>>>> +DEFINE_MTHP_STAT_ATTR(shmem_fallback_charge, MTHP_STAT_SHMEM_FALL= BACK_CHARGE); > >>>>>> DEFINE_MTHP_STAT_ATTR(split, MTHP_STAT_SPLIT); > >>>>>> DEFINE_MTHP_STAT_ATTR(split_failed, MTHP_STAT_SPLIT_FAILED); > >>>>>> DEFINE_MTHP_STAT_ATTR(split_deferred, MTHP_STAT_SPLIT_DEFERRED); > >>>>>> @@ -581,9 +581,9 @@ static struct attribute *stats_attrs[] =3D { > >>>>>> &anon_fault_fallback_charge_attr.attr, > >>>>>> &swpout_attr.attr, > >>>>>> &swpout_fallback_attr.attr, > >>>>>> - &file_alloc_attr.attr, > >>>>>> - &file_fallback_attr.attr, > >>>>>> - &file_fallback_charge_attr.attr, > >>>>>> + &shmem_alloc_attr.attr, > >>>>>> + &shmem_fallback_attr.attr, > >>>>>> + &shmem_fallback_charge_attr.attr, > >>>>>> &split_attr.attr, > >>>>>> &split_failed_attr.attr, > >>>>>> &split_deferred_attr.attr, > >>>>>> diff --git a/mm/shmem.c b/mm/shmem.c > >>>>>> index 921d59c3d669..f24dfbd387ba 100644 > >>>>>> --- a/mm/shmem.c > >>>>>> +++ b/mm/shmem.c > >>>>>> @@ -1777,7 +1777,7 @@ static struct folio *shmem_alloc_and_add_fol= io(struct vm_fault *vmf, > >>>>>> if (pages =3D=3D HPAGE_PMD_NR) > >>>>>> count_vm_event(THP_FILE_FALLBACK); > >>>>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >>>>>> - count_mthp_stat(order, MTHP_STAT_FILE_FALL= BACK); > >>>>>> + count_mthp_stat(order, MTHP_STAT_SHMEM_FAL= LBACK); > >>>>>> #endif > >>>>>> order =3D next_order(&suitable_orders, ord= er); > >>>>>> } > >>>>>> @@ -1804,8 +1804,8 @@ static struct folio *shmem_alloc_and_add_fol= io(struct vm_fault *vmf, > >>>>>> count_vm_event(THP_FILE_FALLBACK_C= HARGE); > >>>>>> } > >>>>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >>>>>> - count_mthp_stat(folio_order(folio), MTHP_S= TAT_FILE_FALLBACK); > >>>>>> - count_mthp_stat(folio_order(folio), MTHP_S= TAT_FILE_FALLBACK_CHARGE); > >>>>>> + count_mthp_stat(folio_order(folio), MTHP_S= TAT_SHMEM_FALLBACK); > >>>>>> + count_mthp_stat(folio_order(folio), MTHP_S= TAT_SHMEM_FALLBACK_CHARGE); > >>>>>> #endif > >>>>>> } > >>>>>> goto unlock; > >>>>>> @@ -2181,7 +2181,7 @@ static int shmem_get_folio_gfp(struct inode = *inode, pgoff_t index, > >>>>>> if (folio_test_pmd_mappable(folio)) > >>>>>> count_vm_event(THP_FILE_ALLOC); > >>>>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >>>>>> - count_mthp_stat(folio_order(folio), MTHP_S= TAT_FILE_ALLOC); > >>>>>> + count_mthp_stat(folio_order(folio), MTHP_S= TAT_SHMEM_ALLOC); > >>>>>> #endif > >>>>>> goto alloced; > >>>>>> } > >>>>>> -- > >>>>>> 2.43.0 > >>>>>> > >>>>> > > Thanks Barry