From: Brendan Jackman <jackmanb@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/page_alloc: Add lockdep assertion for pageblock type change
Date: Tue, 4 Mar 2025 12:50:15 +0000 [thread overview]
Message-ID: <Z8b3B42jwRpnPIs7@google.com> (raw)
In-Reply-To: <0f120624-3ae9-4273-b349-b10d813a4e65@redhat.com>
On Mon, Mar 03, 2025 at 06:06:12PM +0100, David Hildenbrand wrote:
> > > But I am not sure why memmap_init_zone_device() would have to set the
> > > migratetype at all? Because migratetype is a buddy concept, and
> > > ZONE_DEVICE does not interact with the buddy to that degree.
> > >
> > > The comment in __init_zone_device_page states:
> > >
> > > "Mark the block movable so that blocks are reserved for movable at
> > > startup. This will force kernel allocations to reserve their blocks
> > > rather than leaking throughout the address space during boot when
> > > many long-lived kernel allocations are made."
> >
> > Uh, yeah I was pretty mystified by that. It would certainly be nice if
> > we can just get rid of this modification path.
> >
> > > But that just dates back to 966cf44f637e where we copy-pasted that code.
> > >
> > > So I wonder if we could just
> > >
> > > diff --git a/mm/mm_init.c b/mm/mm_init.c
> > > index 57933683ed0d1..b95f545846e6e 100644
> > > --- a/mm/mm_init.c
> > > +++ b/mm/mm_init.c
> > > @@ -1002,19 +1002,11 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn,
> > > page->zone_device_data = NULL;
> > > /*
> > > - * Mark the block movable so that blocks are reserved for
> > > - * movable at startup. This will force kernel allocations
> > > - * to reserve their blocks rather than leaking throughout
> > > - * the address space during boot when many long-lived
> > > - * kernel allocations are made.
> > > - *
> > > - * Please note that MEMINIT_HOTPLUG path doesn't clear memmap
> > > - * because this is done early in section_activate()
> > > + * Note that we leave pageblock migratetypes uninitialized, because
> > > + * they don't apply to ZONE_DEVICE.
> > > */
> > > - if (pageblock_aligned(pfn)) {
> > > - set_pageblock_migratetype(page, MIGRATE_MOVABLE);
> > > + if (pageblock_aligned(pfn))
> > > cond_resched();
> > > - }
> > > /*
> > > * ZONE_DEVICE pages other than MEMORY_TYPE_GENERIC are released
> >
> > memory-model.rst says:
> >
> > > Since the
> > > page reference count never drops below 1 the page is never tracked as
> > > free memory and the page's `struct list_head lru` space is repurposed
> > > for back referencing to the host device / driver that mapped the memory.
>
> That comment will be stale soon. In general, ZONE_DEVICE refcounts can drop
> to 0, but they will never go to the buddy, but will get intercepted on the
> freeing path.
>
> >
> > And this code seems to assume that the whole pageblock is part of the
> > ZONE_DEVICE dance, it would certainly make sense to me...
>
> Sorry, I didn't get your final conclusion: do you thing we don't have to
> initialize the migratetype, or do you think there is reason to still do it?
Sorry yeah, I was concluding that I don't see any reason to set the
migratetype here. But, given I didn't even notice this code path until
your review here I am not feeling too confident about changing it.
I can try to stare it some more and hopefully some courage will build
up! I probably also need to find a way to run a system that uses
ZONE_DEVICE for my local testing...
prev parent reply other threads:[~2025-03-04 12:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-03 12:13 Brendan Jackman
2025-03-03 13:11 ` David Hildenbrand
2025-03-03 13:48 ` David Hildenbrand
2025-03-03 13:55 ` Brendan Jackman
2025-03-03 14:06 ` David Hildenbrand
2025-03-03 16:00 ` Brendan Jackman
2025-03-03 17:06 ` David Hildenbrand
2025-03-04 12:50 ` Brendan Jackman [this message]
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=Z8b3B42jwRpnPIs7@google.com \
--to=jackmanb@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=vbabka@suse.cz \
/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