From: Alistair Popple <apopple@nvidia.com>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de, bp@alien8.de,
dave.hansen@linux.intel.com, david@kernel.org, kees@kernel.org,
mingo@redhat.com, rppt@kernel.org, tglx@kernel.org,
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 v4 1/8] mm: fix stale ZONE_DEVICE refcount comment
Date: Tue, 7 Jul 2026 12:16:53 +1000 [thread overview]
Message-ID: <akxg0LSkohWvxj5w@nvdebian.thelocal> (raw)
In-Reply-To: <20260603080152.64728-2-lizhe.67@bytedance.com>
On 2026-06-03 at 18:01 +1000, Li Zhe <lizhe.67@bytedance.com> wrote...
> The comment in __init_zone_device_page() still uses the old
> MEMORY_TYPE_* names and implies that FS_DAX pages regain a
> refcount of 1 in the free path. That no longer matches the code.
Correct, obviously I missed this comment when updating the code.
> Update the comment to describe the current policy correctly:
> MEMORY_DEVICE_GENERIC pages regain a refcount of 1 in the free path,
> while the remaining ZONE_DEVICE types start from 0 here and raise the
> count again when the allocator or driver hands the page out.
It would be nice to make MEMORY_DEVICE_GENERIC the same one day too. But this
change looks accurate to me:
Reviewed-by: Alistair Popple <apopple@nvidia.com>
> No functional change intended.
>
> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
> ---
> mm/mm_init.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index f9f8e1af921c..35de3b6a186d 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1027,13 +1027,9 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn,
> }
>
> /*
> - * ZONE_DEVICE pages other than MEMORY_TYPE_GENERIC are released
> - * directly to the driver page allocator which will set the page count
> - * to 1 when allocating the page.
> - *
> - * MEMORY_TYPE_GENERIC and MEMORY_TYPE_FS_DAX pages automatically have
> - * their refcount reset to one whenever they are freed (ie. after
> - * their refcount drops to 0).
> + * MEMORY_DEVICE_GENERIC pages regain a refcount of 1 in the free
> + * path. The remaining ZONE_DEVICE types start from 0 here and raise
> + * the count again when the allocator or driver hands the page out.
> */
> switch (pgmap->type) {
> case MEMORY_DEVICE_FS_DAX:
> --
> 2.20.1
next prev parent reply other threads:[~2026-07-07 2:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 8:01 [PATCH v4 0/8] mm: speed up ZONE_DEVICE memmap initialization Li Zhe
2026-06-03 8:01 ` [PATCH v4 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-07-07 2:16 ` Alistair Popple [this message]
2026-06-03 8:01 ` [PATCH v4 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-06-03 8:01 ` [PATCH v4 3/8] mm: add a set_page_section_from_pfn() helper Li Zhe
2026-06-03 8:01 ` [PATCH v4 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-06-03 8:01 ` [PATCH v4 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-06-03 8:01 ` [PATCH v4 6/8] string: introduce memcpy_streaming() helpers Li Zhe
2026-06-07 19:08 ` Borislav Petkov
2026-06-09 12:01 ` Li Zhe
2026-06-10 19:19 ` Borislav Petkov
2026-06-11 9:38 ` Li Zhe
2026-06-03 8:01 ` [PATCH v4 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-06-03 8:01 ` [PATCH v4 8/8] mm: use memcpy_streaming() in zone-device template copies Li Zhe
2026-06-04 8:14 ` [PATCH v4 0/8] mm: speed up ZONE_DEVICE memmap initialization Alistair Popple
2026-06-05 9:52 ` Li Zhe
2026-07-07 2:12 ` Alistair Popple
2026-07-07 6:35 ` 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=akxg0LSkohWvxj5w@nvdebian.thelocal \
--to=apopple@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--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.