[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <13d1fe66-9f34-47d3-b174-516ffb706aa1@redhat.com>
Date: Wed, 16 Jul 2025 10:20:26 +0200
From: David Hildenbrand <david@...hat.com>
To: Anthony Yznaga <anthony.yznaga@...cle.com>, davem@...emloft.net,
andreas@...sler.com, arnd@...db.de, muchun.song@...ux.dev,
osalvador@...e.de, akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
mhocko@...e.com
Cc: linux-mm@...ck.org, sparclinux@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
alexghiti@...osinc.com, agordeev@...ux.ibm.com, anshuman.khandual@....com,
christophe.leroy@...roup.eu, ryan.roberts@....com, will@...nel.org
Subject: Re: [PATCH 1/3] sparc64: remove hugetlb_free_pgd_range()
On 16.07.25 03:26, Anthony Yznaga wrote:
> The sparc implementation of hugetlb_free_pgd_range() is identical
> to free_pgd_range() with the exception of checking for and skipping
> possible leaf entries at the PUD and PMD levels.
And the pgd loop was optimized out, because probably not applicable.
> These checks are
> unnecessary because any huge pages have been freed and their PTEs
> cleared by the time page tables needed to map them are freed.
Do we know why that handling was added in the first place, and why it no
longer applies?
These is_hugetlb_pmd/is_hugetlb_pud are rather weird on the code path.
Looks like a very nice cleanup.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists