| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2ed6c403-b7a4-4e03-92f3-7debd05d965a@redhat.com> Date: Thu, 22 Aug 2024 00:10:58 +0200 From: David Hildenbrand <david@...hat.com> To: Barry Song <21cnbao@...il.com> Cc: akpm@...ux-foundation.org, linux-mm@...ck.org, baolin.wang@...ux.alibaba.com, chrisl@...nel.org, hanchuanhua@...o.com, ioworker0@...il.com, kaleshsingh@...gle.com, kasong@...cent.com, linux-kernel@...r.kernel.org, ryan.roberts@....com, v-songbaohua@...o.com, ziy@...dia.com, yuanshuai@...o.com, Usama Arif <usamaarif642@...il.com> Subject: Re: [PATCH v2 2/2] mm: collect the number of anon large folios on split_deferred list On 22.08.24 00:01, Barry Song wrote: > On Thu, Aug 22, 2024 at 5:39 AM David Hildenbrand <david@...hat.com> wrote: >> >> On 12.08.24 00:49, Barry Song wrote: >>> From: Barry Song <v-songbaohua@...o.com> >>> >>> When an mTHP is added to the deferred_list, its partial pages >>> are unused, leading to wasted memory and potentially increasing >>> memory reclamation pressure. >>> >>> Detailing the specifics of how unmapping occurs is quite difficult >>> and not that useful, so we adopt a simple approach: each time an >>> mTHP enters the deferred_list, we increment the count by 1; whenever >>> it leaves for any reason, we decrement the count by 1. >>> >>> Signed-off-by: Barry Song <v-songbaohua@...o.com> >>> --- >>> Documentation/admin-guide/mm/transhuge.rst | 5 +++++ >>> include/linux/huge_mm.h | 1 + >>> mm/huge_memory.c | 6 ++++++ >>> 3 files changed, 12 insertions(+) >>> >>> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst >>> index 9fdfb46e4560..7072469de8a8 100644 >>> --- a/Documentation/admin-guide/mm/transhuge.rst >>> +++ b/Documentation/admin-guide/mm/transhuge.rst >>> @@ -532,6 +532,11 @@ nr_anon >>> These huge pages could be entirely mapped or have partially >>> unmapped/unused subpages. >>> >>> +nr_split_deferred >>> + the number of anon huge pages which have been partially unmapped >>> + and put onto split queue. Those unmapped subpages are also unused >>> + and temporarily wasting memory. >> >> The name suggests something else ... like a counter of how many have >> been deferred split :) >> >> Would "nr_anon_partially_mapped" "nr_anon_split_pending" (or something >> less mouthful) be clearer? >> >> (likely "anon" really should be part of the name in any case) >> >> The name we chose (and the implied semantics) will likely have >> implications on the handling of Usamas series. >> > > Hi David, > > Your point is quite similar to my V1, though not exactly the same. I aimed to > make the name more meaningful for users. > https://lore.kernel.org/all/20240808010457.228753-3-21cnbao@gmail.com/ > > Ryan felt that the name should be consistent with the existing split_deferred. > https://lore.kernel.org/all/36e8f1be-868d-4bce-8f32-e2d96b8b7af3@arm.com/#t Right, it's an increasing counter of how often we added something to the deferred split queue. It's more like a low-level primitive, although currently only used for one reason (anon + partial mapping). > > It seems that the existing split_deferred may now be less optimal with > Usama's series, as entirely_mapped folios might also be on the list. Yes. > > Ryan is out right now, but I suppose he will be convinced that > "nr_anon_partially_mapped" is probably a better name once > he returns and reviews Usama's series. :-) Maybe ;) At least it's clear from the name what we are talking about. -- Cheers, David / dhildenb
Powered by blists - more mailing lists