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 7BE31C2BD09 for ; Tue, 9 Jul 2024 08:13:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F1CC6B009A; Tue, 9 Jul 2024 04:13:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A0BA6B009D; Tue, 9 Jul 2024 04:13:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E83136B009E; Tue, 9 Jul 2024 04:13:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C48EA6B009A for ; Tue, 9 Jul 2024 04:13:26 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 76245A4BCB for ; Tue, 9 Jul 2024 08:13:26 +0000 (UTC) X-FDA: 82319499612.09.939AADD Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf10.hostedemail.com (Postfix) with ESMTP id AAD66C0010 for ; Tue, 9 Jul 2024 08:13:24 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lfP9Z+7S; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720512790; 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=Ab5Y1VUQuoOzyq8nuVbYD/Ed9ffD45Te09SgAn6tRXo=; b=NVFRAbcUF9QkXttcajvbLohqC9vdbjyt0qLCvWjnZvXdXWd63gdfwMsl3XU/zrQGhMIhTo tXQhZVP8B+pk9TshPnb6MbljV3B5ETkO46+wxPy/PJl5FIicsqYyv9ChdbYcenmTPT7fr+ /0hOt1AVsdJwiir73UWg7PZzmUQZhG0= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lfP9Z+7S; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720512790; a=rsa-sha256; cv=none; b=RPOGCNfhIWIL3XGtakcu5/Z5+pwzDrx57rsz+1V01Bn3fmQVWn3fltZt5TfUHPCrHf9rEt rRkGXcmGWPeNkRu85lrx+Pg7mjgWInJfvYYukf/JAv2dUmLSDIXTvzTtoAWGzez/aUpPgz AUI8pzaiZeOJsDDFjVxaiWh4E6d42uY= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4ef2006dcdbso1697678e0c.3 for ; Tue, 09 Jul 2024 01:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720512804; x=1721117604; 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=Ab5Y1VUQuoOzyq8nuVbYD/Ed9ffD45Te09SgAn6tRXo=; b=lfP9Z+7SWDJBUWY5Na59AkI3BmWc8pFRrVyrTJST7IXG/vdZVRed6RUGD9eO+tXwmK HMlsoH8rRH+p8DZQRtA8U81UxjCurJ5DENldsyTi7OfI3ypPTZi4wf8tZrtz28HtJsu1 3d3qfi75nOLVObDn1MUFbdjyY98xn5RrqcNzQ4hmEyfmM7UWR7dQz9ntZycJLbHXXQnr Sx9yrEPKn1Vmy7/XcRv5nCYrUxjXev9eBv0+qHvH9cq9jUSfMkEneLQVzWU5nPk6ZXuA smNrn7xxjcDfhfjQ1ZDS0n2PbCN1vec61pRaR3qLLgrCpXd/E0IWYrbye+d4q/NGCUHx WLSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720512804; x=1721117604; 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=Ab5Y1VUQuoOzyq8nuVbYD/Ed9ffD45Te09SgAn6tRXo=; b=Pk/W3BT3m4dawNvxDIsULVjtYqoPD6Edfs+qt39xOKOrGRXj6F7PMccEfLMq3aG00a 9jL1GIEKu+StppJvQEKbCT/SnugaiFnGBiS6g1dxGOQcqSzI74C6w/IULOJbMuEiq56N HOGXUw2MXRLotAmuHQXrTKGoERywdKxPZn88Lrjx6iRQstzfqwK5gAziMEaREnG6+CZO T2n+wuK6H4g/Kcrn2RQd2rHtx6nQ++grPu0PxGr1Fc66otjboIewvhae3b/AUPTlU9Du Wa4cRysFaWSNYTuY4+aJwczAmZYaqk8hf6xprROwnOqlPZd0GQBb5MAIceWxfoATeMSx glYg== X-Forwarded-Encrypted: i=1; AJvYcCU2EJcPJhiFJNOAHECiRgTgB/7aXe6NfzmELbl99oIGHkP6Wty0HlVGHbBgR+8KVdsUiPp/6qPnod1il56N01WF2WA= X-Gm-Message-State: AOJu0Yw2ctaCiLtgF88niWvyOZCrnioODUwlKjz0OtmRkz4XSBaCqOiR SQfoXCr2PfnhRp/YqA37sG2usNx5o62TRaC1M8MICXKbMi+vtQW6wsyWVr18z0XqKJhvEMt2Sd/ awM8rCYz3QqAloOQHnYLj2OLQ1pE= X-Google-Smtp-Source: AGHT+IHYObEmYfEECsSxwORrF9H7EXEX//ZVvH5n3ik1g0i4zYI7j1Iiv05il1fPKrHOmh6dzKmsRS1cnkI7Hj9ZGGc= X-Received: by 2002:a05:6122:218d:b0:4ed:36f:9b38 with SMTP id 71dfb90a1353d-4f33f29bc51mr2165474e0c.9.1720512802064; Tue, 09 Jul 2024 01:13:22 -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: <70ac8a5d-f6cf-41e6-b295-cd40b81fa85e@arm.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 9 Jul 2024 20:13:10 +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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AAD66C0010 X-Stat-Signature: cgoy5sx8pf5cpgkuk9nncdn86yqtqxt8 X-HE-Tag: 1720512804-929895 X-HE-Meta: U2FsdGVkX18XHjff0qoWqZbhj9fMnAy4eAAiVfPR52wDuG+58mqf9VfrIyu8Pm8EflJzHGK+BC166vP3u6pwG2Ru+ncdCvfdPUPL5O5Qv83l7CjkbBNJiSGPXR+XX6ehuXxtHp+lFE5y2Fpc9HNU4pOTPIQKgu5RIFflVaFBISwKAwzsZIgv/vCE5CI0Gc08zgCNEQ9AD0Oq78TS9D+O+iMfBeAmfp8WW4L79NjUvtGoiT2PM+Afqwd9AdPvr83DlnX8MednffxMAXO0IsgKWdoRljqSy6YRg89Sw9nb7Drk6tZZszi6feGTUkFB+Ob7JVJ0WibhGvRYgcEkZNrTrgef3a6cel8B0q9p+M5YpynvJ1gzyVRytCBjv/Pex3k2Bj3bFXt5diiE/u6qlZwZeOsohnGB73WSsXE5MPN+33Hg4Vpp4/nfN9WlqL4u8h5EE8zLsRrVMiT/2OS8DYvOWKkVRV6hDOKdm0mrCGTjcOvucxhPyZDNn0XJzIM4NoM8CpRGifIlsI1fX4DesVRFnT5mg4RghNhCGUyg5GVVVvsHNVphbn9JvmjT3AARrG0Dw3xrCH3KLI3zQMzwqauAiSUPFWq0f3xaSmW2U50TH9XgKmb+5HiseoZaBPQdkgdMLA+NFRlTuGcnRMP2BLDzs/oBEkhYBFEZF/nto/soVboqw9TxcdlMhEjEqjjWGkOkCktJs0UmmaTaIvy1N9pEQvnMQfOd9XbVuS9QBjIFt7BhUsjXDwdsULoZ8pPtDWY5ZYQKe2W4c6Jr2/GUYiWMEbA11oBwSsAKKpMeS/TVrNAEMMfACTUIjxpA/9Rgnuq+y+H6zW3VUctjShNwXWxSTEswMekRidi9iUV8Ttiki1krvKixow5FwIYdI7Q9FsJQvpirqTKB1oDsmSV/jAKt81Vx/dhkGsWNQkQW7UgUYL/OMePBJvBaa0EKOgQWM+eGZtQcaip2k+Sx/Yz41aC ZhuiVpyR yOBdxY5RFnFtsbe8M3MjsWGW9lMsha8MChmeCthNuBYYSX77It8IfymE2LGBMmLZcTzJyW9PWMgJnh6laoTEYZJzeRaN0TAPtl2piky6cydt02IxoONb2+ytjmNCPOUcdVtkNU9xnVjZcA1u4GUgrn2BCu4n4ZqPX9c1FBc7oVOEPW5wtkjLfe+MUN7I6NNvZRkC7U2p5AM1z+0F1MnXQGrJB0cWXvsBv5zKPvpNkNImHmpDkH9RunZCgyQ4w2pz7pVZsjbGOn/8ymuNNuNUJ4ldUYGzdH0uXPKL281Veq8PTXT60MmIukPz84BLoq4Zoex4MS+QJcnhyIMjE+eOCPCEWwcE5uFD0TafpAJzeZfLQSmTzpst0TXP32HEXTn2X2wsTG5Cl1nFB+UyUCTNruBoWlDTASqV/mgbhdJqgIayH5rAalc0KQEej5wASMNQpoprL 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 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, whic= h > >>>> rather confusingly refer to shmem THP and do not include any other t= ypes > >>>> of file pages. This is inconsistent since in most other places in th= e > >>>> kernel, THP counters are explicitly separated for anon, shmem and fi= le > >>>> flavours. However, we are stuck with it since it constitutes a user = ABI. > >>>> > >>>> Recently, commit 66f44583f9b6 ("mm: shmem: add mTHP counters for > >>>> anonymous shmem") added equivalent mTHP stats for shmem, keeping the > >>>> same "file_" prefix in the names. But in future, we may want to add > >>>> extra stats to cover actual file pages, at which point, it would all > >>>> 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 recall > >>> we discussed this > >>> before [1], and it seems that inconsistency is a concern? > >> > >> Embarrassingly, I don't recall that converstation at all :-| but at le= ast 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_, an= d add both > >> shmem and pagecache counts to those counters, meaning we can keep the = same name > >> as legacy THP counters. But those legacy THP counters only count shmem= , 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 r= isk that > >> user space relies on them and if they were to dramatically increase du= e to > >> pagecache addition now that could break things). In that case, there i= s still > >> inconsistency, but its worse; the names are consistent but the semanti= cs 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 roll = 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* cou= nt > shmem. They don't count pagecache. So perhaps the change should be "...ev= ery > time a shmem huge page (dispite being named after "file", the counter mea= sures > 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. 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 change t= here. > > What do you think? > > > > > > diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation= /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 attempted > > + 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 instead > > - 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/05d0096e4ec3e572d1d52d33a31a6613= 21ac1551.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 with= mm > >>>> selftests; no regressions observed. > >>>> > >>>> The backstory here is that I'd like to introduce some counters for r= egular file > >>>> folio allocations to observe how often large folio allocation succee= ds, but > >>>> these shmem counters are named "file" which is going to make things = confusing. > >>>> So hoping to solve that before commit 66f44583f9b6 ("mm: shmem: add = mTHP > >>>> counters for anonymous shmem") goes upstream (it is currently in mm-= stable). > >>>> > >>>> Admittedly, this change means the mTHP stat names are not the same a= s 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 "p= gcache_" > >>>> stats for the regular file memory, which is even more inconsistent I= MHO. I guess > >>>> the alternative is to count both shmem and file in these mTHP stats = (that's how > >>>> they were documented anyway) but I think it's better to be able to c= onsider 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/Documentat= ion/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 spac= e > >>>> 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 successfully > >>>> allocated. > >>>> > >>>> -file_fallback > >>>> - is incremented if a file huge page is attempted to be alloca= ted > >>>> +shmem_fallback > >>>> + is incremented if a shmem huge page is attempted to be alloc= ated > >>>> but fails and instead falls back to using small pages. > >>>> > >>>> -file_fallback_charge > >>>> - is incremented if a file huge page cannot be charged and ins= tead > >>>> +shmem_fallback_charge > >>>> + is incremented if a shmem huge page cannot be charged and in= stead > >>>> falls back to using small pages even though the allocation w= as > >>>> 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, MTHP_= STAT_ANON_FAULT_FALLBACK); > >>>> DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FA= ULT_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_FALLBACK= _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_FALLBA= CK_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_folio= (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_FALLBA= CK); > >>>> + count_mthp_stat(order, MTHP_STAT_SHMEM_FALLB= ACK); > >>>> #endif > >>>> order =3D next_order(&suitable_orders, order= ); > >>>> } > >>>> @@ -1804,8 +1804,8 @@ static struct folio *shmem_alloc_and_add_folio= (struct vm_fault *vmf, > >>>> count_vm_event(THP_FILE_FALLBACK_CHA= RGE); > >>>> } > >>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >>>> - count_mthp_stat(folio_order(folio), MTHP_STA= T_FILE_FALLBACK); > >>>> - count_mthp_stat(folio_order(folio), MTHP_STA= T_FILE_FALLBACK_CHARGE); > >>>> + count_mthp_stat(folio_order(folio), MTHP_STA= T_SHMEM_FALLBACK); > >>>> + count_mthp_stat(folio_order(folio), MTHP_STA= T_SHMEM_FALLBACK_CHARGE); > >>>> #endif > >>>> } > >>>> goto unlock; > >>>> @@ -2181,7 +2181,7 @@ static int shmem_get_folio_gfp(struct inode *i= node, 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_STA= T_FILE_ALLOC); > >>>> + count_mthp_stat(folio_order(folio), MTHP_STA= T_SHMEM_ALLOC); > >>>> #endif > >>>> goto alloced; > >>>> } > >>>> -- > >>>> 2.43.0 > >>>> > >>> Thanks Barry