From patchwork Tue Jul 9 01:44:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Barry Song <21cnbao@gmail.com> X-Patchwork-Id: 13727168 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 307B1C3271E for ; Tue, 9 Jul 2024 01:44:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA6A26B0099; Mon, 8 Jul 2024 21:44:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A55A56B009B; Mon, 8 Jul 2024 21:44:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91CD66B009D; Mon, 8 Jul 2024 21:44:37 -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 74CB76B0099 for ; Mon, 8 Jul 2024 21:44:37 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 21506161613 for ; Tue, 9 Jul 2024 01:44:37 +0000 (UTC) X-FDA: 82318519794.15.179BCA1 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf02.hostedemail.com (Postfix) with ESMTP id 39C9780011 for ; Tue, 9 Jul 2024 01:44:35 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P7lBbIIa; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.214.170 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=1720489444; 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=i7JwVPtkjnXuNlozYkqpZNw80t4p50gXWxEmF3epp84=; b=k7p9F6stCzmMiZxz4d5LNmJaJFSd3awc6p/4wLvCuIaEI39U6rRvy8PAcTNDvutAULTzi2 PcblsgDSJtuQS2dN3MZn25soPUs2EqmwYPOMigS4vvSjZSUGSh4m6IVzPaxBUKJSaE8w4U YY7lCTam4zf/SDLN2IFQ2ALa4GY69Dw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720489444; a=rsa-sha256; cv=none; b=kJCdEPJsXYnmhLyYThutPyJttWO1Nhc+cU/ULiN9ixsGqU8bieiI33ntqjG6cj9JJ77pmZ KSAdly+YJx6rWQB5cZpqiLkkZhynzLzLNjdxG2apCpNsMp86gc4npMIViaOKTSVlUQwJL4 n1eFbTXXp1Y+p+Q5H1v8RsgbaGd9BkU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P7lBbIIa; spf=pass (imf02.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1f9de13d6baso27384885ad.2 for ; Mon, 08 Jul 2024 18:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720489474; x=1721094274; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=i7JwVPtkjnXuNlozYkqpZNw80t4p50gXWxEmF3epp84=; b=P7lBbIIaaHuzMwpm96I4wLgsy5/K9hDDlv9ekamrY/3Zpuy85rj3JQ42Jjqbdyc06J HSTckSRbuQf1V2uFj5A5w0pb56JtU4KK1Hy0wk+DQLHozHWfHMwnNZ13eUw5WqJVuy85 +nuUnU9uYaYsWKsEAqS0V/fuC7/QXwtWqoow09C82kqRVieH9hAKqtCdiUOcL3AHopQk srt1Z/rDV2eerKHDzSbYNdmfCoilPc0lWcUvlqDxwlKoGgDfIV9ZjCBlErC9O7kKIhDU rBHoCO/GYvUId6LKm+esC+1h6VykjHzqLidcVxb5dadRHFS8EMuscGRYmjtYGuxfLyZe QlHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720489474; x=1721094274; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=i7JwVPtkjnXuNlozYkqpZNw80t4p50gXWxEmF3epp84=; b=Vu7kIOiaibs/Ei5zPjKK+FHjZq6Cd+RW882D7LTMLLFWLrzKy78bQcteb00Z24Ys3P 4+bidiROt1hkGL/plumq5JvDNTG7DOZdutJROVWeEJr3VSjFZ6PZ+JWn19seo8eaup/D tSkBeSstjgn0qv1+ZcVI4ul7y98eM7QPHvQHTUAtpk9LzN0dd3C0p1ylLYK9YE45yXN5 ht14rIlqhNCAlwFCJtrEpAH9O7m4Qz7bSXYXo9KpZa/Tpy/0SXrJk2DFI0T7tR2EXCVS 8F7APtHIOWov96rO3Ql9nPRC1PD4FCrOIczBPFh8uGsfdbpptddk/DGm85ZgnlvV1ow3 t+MA== X-Forwarded-Encrypted: i=1; AJvYcCVwGihUX8gWFYQpf5eIaUOu4CMcRPFH0D+wnWBKrp6lzc7IBibRu/2m8NRFm59+9DZglRs2Xq4sTLPccyicTLa2qvg= X-Gm-Message-State: AOJu0Yx8y4x0UrUICbbuiY4QG7VucS4vcXzrz/UqLdfsxP8H7TE6IaY+ TIIkPfqc3B3WGoroMoz+E7GQx/s+XVPt0MvAmWIFcWhuZsTu6NdIKOZz+A== X-Google-Smtp-Source: AGHT+IEGRgF6WH6W+fLpO2gg+v0EPIgumYh7bbxFBukp6w+Svkfg/57ie1z+Mr5bos7qmDXFjYhyog== X-Received: by 2002:a05:6a20:4388:b0:1c0:ee57:a9a5 with SMTP id adf61e73a8af0-1c2984ce6bemr962165637.42.1720489473967; Mon, 08 Jul 2024 18:44:33 -0700 (PDT) Received: from localhost.localdomain ([2407:7000:8942:5500:aaa1:59ff:fe57:eb97]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fbb6ab6c53sm4910245ad.153.2024.07.08.18.44.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jul 2024 18:44:33 -0700 (PDT) From: Barry Song <21cnbao@gmail.com> To: ryan.roberts@arm.com Cc: akpm@linux-foundation.org, baohua@kernel.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 Subject: [PATCH v1] mm: shmem: Rename mTHP shmem counters Date: Tue, 9 Jul 2024 13:44:13 +1200 Message-Id: <20240709014413.18044-1-21cnbao@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <744749c3-4506-40d9-ac48-0dbc59689f92@arm.com> References: <744749c3-4506-40d9-ac48-0dbc59689f92@arm.com> MIME-Version: 1.0 X-Stat-Signature: pppfconw795rn5ge74f1q9ksqc9pzqr9 X-Rspamd-Queue-Id: 39C9780011 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720489475-354179 X-HE-Meta: U2FsdGVkX1+khpMsuP+f5kRsQDvejE/gDmxmZix7LA/ReXN8UeFc+x1GiF+UuEpHztu5NblvzrjpdXiBoU2LpnuPOxN70ajaPhesPcYJZFx6Fvd05QBSOTnb9y9E+8i8CKGZjKNPwu4sF2LcfdeUo4jlzagib3OoHd065EqAEy02ZgBmmTbUDOTY8r+t/9UDFaMgnMfEfR96fYCmr8D3I/+NDbIvMIcv9O2j8tnG/0EjeSd5m31mBdQpe1QGFYwLpT54GlSwHDh2BT8TplU3Ip/DDEeeUm0QcxrTwnjDxzpd5mHBfFOmkTjippQnO8xAKcgy2mk+pGxmq+kktEqb9NAsbfGH6YtYYSCs1gP8euQEb36Yn/gUeQSS8IpI6EeFEtlKTCX3bC3ZoPaXhQoqmIPQaF0UXm1CL6zrli0Xvamd8xHL9pG2wSTUD2gOBamCwJB5A5wi4D5JNGMllrxOMhscYnUPDla1Pv6EsDwD2QbRwF4/D1Foo1E/jHxS3yU3untPQV7chYaETiRklHWS0t/a0YJwelcYKlvltce6bHKgRCdaLP66BzW2BDi40f7dPw+qq3umaYgU4yr422IODs2Yg0dOx3vYXvI5jYkCVf7qXfJyLUMQfmLK/OL1VOEgtgdI5pgpJXKzhrWeruL2C5CrfzoC7Z4Cqe27mn6T4/LHgb4C+LghJ20syhiMd+h+k/sBHG98K5vqX2024CPpqo81p5KDGUiyrfWBUXUZ0+udzYdZPk+gB+e1GYa0hNjdZUMfZYSvQN14bahrgtAqfQG1E6ccxpczhVjh3VwWSM1WreeCbxcx4at+LnU23+/nXlCEncaQYQGEqIdMMiCTe9c5el+dmtFWSltMjT8F+rvKSgZ65J2pB+cQrcZH3Vp5qDzA5eqIGKkM63QvWlFDsDhMXkwX6Ca/SHszx8KBTCtjC7UHvTiefTOSfxK4anpOjgRsGATIutU77BTJHAe ZG4TvRrW 2apkA5Ms+WAT0hgXozb/YcToq8HksGKYsTEwlC1CA8O2Q//u5CRU8kl2GLSN/KkBCcF2dSWZSIitGEE/+49Vdkk99C+u+ktYBuOa/0QNoYJxvrZ+GlErU1kDGlPn7YUZBr7IfyJ7oZmJQS4/QNjfSKKzf8jJFnlDFZkpsJc70qQuNcy7o6tr5Zn01Sc5fMVH6MuyIfrklNLAS39qlGJ0hY+gNcVhbvaxNkOHFq9XOuMbcQkaax0ks4rIT+o4yiFqtgtuiNPV+qJ9lqedcRnKQkvcghsjBJ937sR81M6IIeawIYmJOzqsCYuXpLnzzXb8R0NkXafsT7uKNRAEFi7F8chf4LSQh7RmqZLH2cf0ph4mz0iRg4RZpK2U6HKSJfAZpC4U46zBmqZMRJcCp+jztWqYSV0qpNnZ/Sn1n1k95Nt5hU6GSsOnha8Ce6siTGjvX/j+ic3roO0kSG/Ykin5TJoIqgDG9D/dzIaP09D+lP4InTznt7loIkOwNlNzvHBN3VflUE4Jjck6eoYH+J1IVeC5OeMLIo6HUBC4hU1u5VS6LNvE= 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 12:30 AM Ryan Roberts wrote: > > On 08/07/2024 12:36, Barry Song wrote: > > On Mon, Jul 8, 2024 at 11:24 PM Ryan Roberts wrote: > >> > >> The legacy PMD-sized THP counters at /proc/vmstat include > >> thp_file_alloc, thp_file_fallback and thp_file_fallback_charge, which > >> 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 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 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 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 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 semantics 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 ? > > > > > [1] https://lore.kernel.org/linux-mm/05d0096e4ec3e572d1d52d33a31a661321ac1551.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 regular file > >> folio allocations to observe how often large folio allocation succeeds, 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 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 stats (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/Documentation/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 space > >>         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 allocated > >> +shmem_fallback > >> +       is incremented if a shmem huge page is attempted to be allocated > >>         but fails and instead falls back to using small pages. > >> > >> -file_fallback_charge > >> -       is incremented if a file huge page cannot be charged and instead > >> +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, MTHP_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_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_FALLBACK_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[] = { > >>         &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 == HPAGE_PMD_NR) > >>                                 count_vm_event(THP_FILE_FALLBACK); > >>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >> -                       count_mthp_stat(order, MTHP_STAT_FILE_FALLBACK); > >> +                       count_mthp_stat(order, MTHP_STAT_SHMEM_FALLBACK); > >>  #endif > >>                         order = 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_CHARGE); > >>                         } > >>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE > >> -                       count_mthp_stat(folio_order(folio), MTHP_STAT_FILE_FALLBACK); > >> -                       count_mthp_stat(folio_order(folio), MTHP_STAT_FILE_FALLBACK_CHARGE); > >> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_SHMEM_FALLBACK); > >> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_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_STAT_FILE_ALLOC); > >> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_SHMEM_ALLOC); > >>  #endif > >>                         goto alloced; > >>                 } > >> -- > >> 2.43.0 > >> > > Thanks Barry 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