From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Li Zhe <lizhe.67@bytedance.com>,
akpm@linux-foundation.org, apopple@nvidia.com, arnd@arndb.de,
bp@alien8.de, dave.hansen@linux.intel.com, kees@kernel.org,
mingo@redhat.com, rppt@kernel.org, tglx@kernel.org
Cc: linux-arch@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH v5 6/8] string: introduce memcpy_nt() helpers
Date: Mon, 6 Jul 2026 11:18:48 +0200 [thread overview]
Message-ID: <c02d8cd6-a3e8-470f-a7ea-a2f2f666b10c@kernel.org> (raw)
In-Reply-To: <20260701090553.62691-7-lizhe.67@bytedance.com>
On 7/1/26 11:05, Li Zhe wrote:
> Introduce memcpy_nt() and memcpy_nt_drain() for write-once copy sites
> that want a named non-temporal copy primitive plus an explicit ordering
> point. On x86, place the arch-visible wrapper in
> arch/x86/include/asm/string_64.h and map it to the existing
> memcpy_flushcache() backend plus sfence. Architectures that do not
> override the helper fall back to memcpy() and a no-op drain in
> include/linux/string.h.
>
> The immediate user is the ZONE_DEVICE template-copy path. That path
> populates struct page descriptors in a write-once pattern, so most
> destination cachelines are not expected to be reused immediately after
> the copy. A regular cached memcpy() can therefore incur avoidable
> write-allocate traffic and pollute the cache with data that has little
> near-term reuse.
>
> This interface lets callers request that non-temporal-copy semantics
> directly, while x86 simply reuses the existing memcpy_flushcache()
> backend instead of adding another generic memcpy-like wrapper with
> extra selection policy above it.
>
> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
> ---
> arch/x86/include/asm/string_64.h | 16 ++++++++++++++++
> include/linux/string.h | 18 ++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h
> index 4635616863f5..6f36abedc56a 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -100,6 +100,22 @@ static __always_inline void memcpy_flushcache(void *dst, const void *src, size_t
> }
> __memcpy_flushcache(dst, src, cnt);
> }
> +
> +#define __HAVE_ARCH_MEMCPY_NT 1
> +/*
> + * Reuse the existing x86 flushcache backend as the nt copy primitive.
> + * Callers pair it with memcpy_nt_drain() when later stores must be
> + * ordered after the copy.
> + */
> +static __always_inline void memcpy_nt(void *dst, const void *src, size_t cnt)
> +{
> + memcpy_flushcache(dst, src, cnt);
> +}
In particular if you end up with a single function (that jsut requires a write
memory barrier afterwards), please make this
#define memcpy_nt memcpy_nt
instead.
--
Cheers,
David
next prev parent reply other threads:[~2026-07-06 9:18 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 9:05 [PATCH v5 0/8] mm: optimize zone-device memmap initialization Li Zhe
2026-07-01 9:05 ` [PATCH v5 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-07-06 9:11 ` David Hildenbrand (Arm)
2026-07-07 2:28 ` Alistair Popple
2026-07-01 9:05 ` [PATCH v5 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-07-06 9:13 ` David Hildenbrand (Arm)
2026-07-06 11:50 ` Li Zhe
2026-07-06 13:47 ` David Hildenbrand (Arm)
2026-07-07 3:25 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 3/8] mm: add a set_page_section_from_pfn() helper Li Zhe
2026-07-06 9:15 ` David Hildenbrand (Arm)
2026-07-06 11:52 ` Li Zhe
2026-07-06 13:48 ` David Hildenbrand (Arm)
2026-07-07 3:26 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-07-03 14:06 ` Mike Rapoport
2026-07-06 7:45 ` Li Zhe
2026-07-07 3:06 ` Alistair Popple
2026-07-07 6:36 ` Li Zhe
2026-07-07 3:02 ` Alistair Popple
2026-07-07 6:33 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-07-07 3:09 ` Alistair Popple
2026-07-07 6:38 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 6/8] string: introduce memcpy_nt() helpers Li Zhe
2026-07-02 2:16 ` Borislav Petkov
2026-07-02 7:36 ` Li Zhe
2026-07-06 9:18 ` David Hildenbrand (Arm) [this message]
2026-07-06 11:53 ` Li Zhe
2026-07-06 13:49 ` David Hildenbrand (Arm)
2026-07-07 3:28 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-07-02 2:23 ` Borislav Petkov
2026-07-02 7:37 ` Li Zhe
2026-07-03 19:56 ` Borislav Petkov
2026-07-06 7:43 ` Li Zhe
2026-07-06 17:19 ` Borislav Petkov
2026-07-07 11:34 ` Li Zhe
2026-07-01 9:05 ` [PATCH v5 8/8] mm: use memcpy_nt() in zone-device template copies Li Zhe
2026-07-01 23:28 ` [PATCH v5 0/8] mm: optimize zone-device memmap initialization Andrew Morton
2026-07-02 2:24 ` Borislav Petkov
2026-07-02 7:39 ` Li Zhe
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=c02d8cd6-a3e8-470f-a7ea-a2f2f666b10c@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kees@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@kernel.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.