[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f8ba5c8-5bc3-4af2-96d2-2f52ee923ef5@arm.com>
Date: Fri, 9 Aug 2024 10:05:51 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: David Hildenbrand <david@...hat.com>, Barry Song <21cnbao@...il.com>,
akpm@...ux-foundation.org, linux-mm@...ck.org
Cc: chrisl@...nel.org, kaleshsingh@...gle.com, kasong@...cent.com,
linux-kernel@...r.kernel.org, ioworker0@...il.com,
baolin.wang@...ux.alibaba.com, ziy@...dia.com, hanchuanhua@...o.com,
Barry Song <v-songbaohua@...o.com>
Subject: Re: [PATCH RFC 1/2] mm: collect the number of anon large folios
On 09/08/2024 09:58, David Hildenbrand wrote:
> On 09.08.24 10:42, David Hildenbrand wrote:
>>>> Not sure I fully understand why David prefers to do the unaccounting at
>>>> free-time though? It feels unbalanced to me to increment when first mapped but
>>>> decrement when freed. Surely its safer to either use alloc/free or use first
>>>> map/last map?
>>>>
>>>> If using alloc/free isn't there a THP constructor/destructor that prepares the
>>>> deferred list? (My memory may be failing me). Could we use that?
>>>
>>> Additionally, if we wanted to extend (eventually) to track the number of shmem
>>> and file mthps in additional counters, could we also account using similar folio
>>> free-time hooks? If not, it might be an argument to account in rmap_unmap to be
>>> consistent for all?
>>
>> Again, see NR_FILE_THPS handling. No rmap over-complication please.
>
> ... not to mention that it is non-sensical to only count pageache folios that
> are mapped to user space ;)
Yes, good point. I'll get back in my box. :)
Powered by blists - more mailing lists