From: David Hildenbrand <david@redhat.com>
To: Anthony Yznaga <anthony.yznaga@oracle.com>,
davem@davemloft.net, andreas@gaisler.com, arnd@arndb.de,
muchun.song@linux.dev, osalvador@suse.de,
akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com
Cc: linux-mm@kvack.org, sparclinux@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
alexghiti@rivosinc.com, agordeev@linux.ibm.com,
anshuman.khandual@arm.com, christophe.leroy@csgroup.eu,
ryan.roberts@arm.com, will@kernel.org
Subject: Re: [PATCH 1/3] sparc64: remove hugetlb_free_pgd_range()
Date: Wed, 16 Jul 2025 10:20:26 +0200 [thread overview]
Message-ID: <13d1fe66-9f34-47d3-b174-516ffb706aa1@redhat.com> (raw)
In-Reply-To: <20250716012611.10369-2-anthony.yznaga@oracle.com>
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
next prev parent reply other threads:[~2025-07-16 8:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-16 1:26 [PATCH 0/3] drop hugetlb_free_pgd_range() Anthony Yznaga
2025-07-16 1:26 ` [PATCH 1/3] sparc64: remove hugetlb_free_pgd_range() Anthony Yznaga
2025-07-16 8:20 ` David Hildenbrand [this message]
2025-07-16 16:42 ` Anthony Yznaga
2025-07-16 1:26 ` [PATCH 2/3] mm: remove call to hugetlb_free_pgd_range() Anthony Yznaga
2025-07-16 1:26 ` [PATCH 3/3] mm: drop hugetlb_free_pgd_range() Anthony Yznaga
2025-07-16 6:36 ` [PATCH 0/3] " Mike Rapoport
2025-07-16 8:05 ` Oscar Salvador
2025-07-16 8:16 ` Oscar Salvador
2025-07-25 7:50 ` John Paul Adrian Glaubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13d1fe66-9f34-47d3-b174-516ffb706aa1@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alexghiti@rivosinc.com \
--cc=andreas@gaisler.com \
--cc=anshuman.khandual@arm.com \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=christophe.leroy@csgroup.eu \
--cc=davem@davemloft.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).