[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7790f69d-7406-4535-994b-8f4b240269ba@linux.dev>
Date: Wed, 11 Feb 2026 13:31:51 +0000
From: Usama Arif <usama.arif@...ux.dev>
To: "David Hildenbrand (Arm)" <david@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, lorenzo.stoakes@...cle.com,
willy@...radead.org, linux-mm@...ck.org
Cc: fvdl@...gle.com, hannes@...xchg.org, riel@...riel.com,
shakeel.butt@...ux.dev, kas@...nel.org, baohua@...nel.org, dev.jain@....com,
baolin.wang@...ux.alibaba.com, npache@...hat.com, Liam.Howlett@...cle.com,
ryan.roberts@....com, vbabka@...e.cz, lance.yang@...ux.dev,
linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [RFC 2/2] mm: thp: add THP_SPLIT_PMD_PTE_ALLOC_FAILED counter
On 11/02/2026 13:27, David Hildenbrand (Arm) wrote:
> On 2/11/26 13:49, Usama Arif wrote:
>> Add a vmstat counter to track PTE allocation failures during PMD split.
>> This enables monitoring of split failures due to memory pressure after
>> the lazy PTE page table allocation change.
>>
>> The counter is incremented in three places:
>> - __split_huge_pmd(): Main entry point for splitting a PMD
>> - try_to_unmap_one(): When reclaim needs to split a PMD-mapped THP
>> - try_to_migrate_one(): When migration needs to split a PMD-mapped THP
>>
>> Visible via /proc/vmstat as thp_split_pmd_pte_alloc_failed.
>>
>> Signed-off-by: Usama Arif <usama.arif@...ux.dev>
>> ---
>> include/linux/vm_event_item.h | 1 +
>> mm/huge_memory.c | 1 +
>> mm/rmap.c | 3 +++
>> mm/vmstat.c | 1 +
>> 4 files changed, 6 insertions(+)
>>
>> diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
>> index 22a139f82d75f..827c9a8c251de 100644
>> --- a/include/linux/vm_event_item.h
>> +++ b/include/linux/vm_event_item.h
>> @@ -111,6 +111,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
>> THP_DEFERRED_SPLIT_PAGE,
>> THP_UNDERUSED_SPLIT_PAGE,
>> THP_SPLIT_PMD,
>> + THP_SPLIT_PMD_PTE_ALLOC_FAILED,
>
> Probably sufficient to call this THP_SPLIT_PMD_FAILED and count any (future) failures (if any) as well.
>
Makes sense. This was just a patch I was using for testing and I wanted to share.
It was always 0 as I couldnt get split to fail :) But I can rename it as THP_SPLIT_PMD_FAILED
as suggested and we can use for future split failures (hopefully none).
> It's a shame that we called a remapping a "split" and keep causing confusion.
>
Powered by blists - more mailing lists