All of lore.kernel.org
 help / color / mirror / Atom feed
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...


      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 [PATCH v2] mm/page_alloc: Add lockdep assertion for pageblock type change 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 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.