From: Ankur Arora <ankur.a.arora@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
akpm@linux-foundation.org, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org,
acme@kernel.org, namhyung@kernel.org, tglx@linutronix.de,
willy@infradead.org, raghavendra.kt@amd.com,
boris.ostrovsky@oracle.com, konrad.wilk@oracle.com
Subject: Re: [PATCH v5 10/14] x86/mm: Simplify clear_page_*
Date: Fri, 11 Jul 2025 10:26:08 -0700 [thread overview]
Message-ID: <874iviprkf.fsf@oracle.com> (raw)
In-Reply-To: <377d74d6-a7f9-4e94-9276-168a26d49210@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 10.07.25 02:59, Ankur Arora wrote:
>> clear_page_rep() and clear_page_erms() are wrappers around "REP; STOS"
>> variations. Inlining gets rid of an unnecessary CALL/RET (which isn't
>> free when using RETHUNK speculative execution mitigations.)
>> Fixup and rename clear_page_orig() to adapt to the changed calling
>> convention.
>> And, add a comment from Dave Hansen detailing various clearing mechanisms
>> used in clear_page().
>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>> ---
>> arch/x86/include/asm/page_32.h | 6 +++++
>> arch/x86/include/asm/page_64.h | 42 ++++++++++++++++++++++++++--------
>> arch/x86/lib/clear_page_64.S | 39 +++++++------------------------
>> 3 files changed, 46 insertions(+), 41 deletions(-)
>> diff --git a/arch/x86/include/asm/page_32.h b/arch/x86/include/asm/page_32.h
>> index 0c623706cb7e..a8ff43bb9652 100644
>> --- a/arch/x86/include/asm/page_32.h
>> +++ b/arch/x86/include/asm/page_32.h
>> @@ -17,6 +17,12 @@ extern unsigned long __phys_addr(unsigned long);
>> #include <linux/string.h>
>> +/*
>
> /** if this was supposed to be kernel doc (which it looks like it is)
>
>> + * clear_page() - clear kernel page.
>
> "clear a kernel page"
>
> Although I am not sure what a "kernel page" is.
>
> Did you mean "clear a page using a kernel virtual address" ?
Thanks. Yes, this makes way more sense.
> (we have a handful of "kernel page" usages, where we talk about non-user space
> allocations)
>
>> + * @page: address of kernel page
>> + *
>> + * Does absolutely no exception handling.
>> + */
>> static inline void clear_page(void *page)
>> {
>> memset(page, 0, PAGE_SIZE);
>> diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
>> index 015d23f3e01f..28b9adbc5f00 100644
>> --- a/arch/x86/include/asm/page_64.h
>> +++ b/arch/x86/include/asm/page_64.h
>> @@ -40,23 +40,45 @@ extern unsigned long __phys_addr_symbol(unsigned long);
>> #define __phys_reloc_hide(x) (x)
>> -void clear_page_orig(void *page);
>> -void clear_page_rep(void *page);
>> -void clear_page_erms(void *page);
>> +void memzero_page_aligned_unrolled(void *addr, u64 len);
>> +/*
>> + * clear_page() - clear kernel page.> + * @page: address of kernel page
>
> Same comment as above.
--
ankur
next prev parent reply other threads:[~2025-07-11 17:26 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 0:59 [PATCH v5 00/14] mm: folio_zero_user: clearing of page-extents Ankur Arora
2025-07-10 0:59 ` [PATCH v5 01/14] perf bench mem: Remove repetition around time measurement Ankur Arora
2025-07-15 20:04 ` Namhyung Kim
2025-07-10 0:59 ` [PATCH v5 02/14] perf bench mem: Defer type munging of size to float Ankur Arora
2025-07-15 20:05 ` Namhyung Kim
2025-07-16 2:17 ` Ankur Arora
2025-07-10 0:59 ` [PATCH v5 03/14] perf bench mem: Move mem op parameters into a structure Ankur Arora
2025-07-15 20:06 ` Namhyung Kim
2025-07-10 0:59 ` [PATCH v5 04/14] perf bench mem: Pull out init/fini logic Ankur Arora
2025-07-15 20:09 ` Namhyung Kim
2025-07-10 0:59 ` [PATCH v5 05/14] perf bench mem: Switch from zalloc() to mmap() Ankur Arora
2025-07-15 20:09 ` Namhyung Kim
2025-07-10 0:59 ` [PATCH v5 06/14] perf bench mem: Allow mapping of hugepages Ankur Arora
2025-07-15 20:12 ` Namhyung Kim
2025-07-16 2:32 ` Ankur Arora
2025-07-10 0:59 ` [PATCH v5 07/14] perf bench mem: Allow chunking on a memory region Ankur Arora
2025-07-15 20:17 ` Namhyung Kim
2025-07-16 2:34 ` Ankur Arora
2025-07-10 0:59 ` [PATCH v5 08/14] perf bench mem: Refactor mem_options Ankur Arora
2025-07-15 20:18 ` Namhyung Kim
2025-07-10 0:59 ` [PATCH v5 09/14] perf bench mem: Add mmap() workloads Ankur Arora
2025-07-15 20:20 ` Namhyung Kim
2025-07-16 2:40 ` Ankur Arora
2025-07-10 0:59 ` [PATCH v5 10/14] x86/mm: Simplify clear_page_* Ankur Arora
2025-07-11 11:47 ` David Hildenbrand
2025-07-11 17:26 ` Ankur Arora [this message]
2025-07-11 19:03 ` David Hildenbrand
2025-07-11 19:24 ` Ankur Arora
2025-07-11 19:27 ` David Hildenbrand
2025-07-10 0:59 ` [PATCH v5 11/14] x86/clear_page: Introduce clear_pages() Ankur Arora
2025-07-10 0:59 ` [PATCH v5 12/14] mm: add config option for clearing page-extents Ankur Arora
2025-07-10 7:58 ` Andrew Morton
2025-07-10 16:31 ` Ankur Arora
2025-07-11 11:39 ` David Hildenbrand
2025-07-11 17:25 ` Ankur Arora
2025-07-11 19:14 ` David Hildenbrand
2025-07-11 19:35 ` Ankur Arora
2025-07-11 11:40 ` David Hildenbrand
2025-07-11 17:32 ` Ankur Arora
2025-07-11 19:26 ` David Hildenbrand
2025-07-11 19:42 ` Ankur Arora
2025-07-14 20:35 ` Ankur Arora
2025-07-15 20:59 ` David Hildenbrand
2025-07-10 0:59 ` [PATCH v5 13/14] mm: memory: support " Ankur Arora
2025-07-11 11:44 ` David Hildenbrand
2025-07-11 13:27 ` Raghavendra K T
2025-07-11 17:39 ` Ankur Arora
2025-07-15 22:08 ` David Hildenbrand
2025-07-16 3:19 ` Ankur Arora
2025-07-16 8:03 ` David Hildenbrand
2025-07-16 17:54 ` Ankur Arora
2025-07-10 0:59 ` [PATCH v5 14/14] x86/clear_pages: Support clearing of page-extents Ankur Arora
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=874iviprkf.fsf@oracle.com \
--to=ankur.a.arora@oracle.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.