Message-ID: <1539a8cb-4cd7-40dd-9949-a2c8f7e272b9@kernel.org>
Date: Thu, 15 Jan 2026 13:57:49 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linuxppc-dev@...ts.ozlabs.org,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, linux-doc@...r.kernel.org,
 virtualization@...ts.linux.dev, Andrew Morton <akpm@...ux-foundation.org>,
 Oscar Salvador <osalvador@...e.de>, "Liam R. Howlett"
 <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>,
 Mike Rapoport <rppt@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>,
 Michal Hocko <mhocko@...e.com>, Jonathan Corbet <corbet@....net>,
 Madhavan Srinivasan <maddy@...ux.ibm.com>,
 Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>, Arnd Bergmann
 <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jerrin Shaji George <jerrin.shaji-george@...adcom.com>,
 "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>,
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, Zi Yan <ziy@...dia.com>
Subject: Re: [PATCH v2 04/23] mm/balloon_compaction: centralize basic page
 migration handling

>>   #endif /* CONFIG_BALLOON_COMPACTION */
>> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
>> index 03c5dbabb1565..5444c61bb9e76 100644
>> --- a/mm/balloon_compaction.c
>> +++ b/mm/balloon_compaction.c
>> @@ -232,20 +232,49 @@ static void balloon_page_putback(struct page *page)
>>   	spin_unlock_irqrestore(&b_dev_info->pages_lock, flags);
>>   }
>>
>> -/* move_to_new_page() counterpart for a ballooned page */
>>   static int balloon_page_migrate(struct page *newpage, struct page *page,
>>   		enum migrate_mode mode)
> 
> I honestly wonder if page should be 'oldpage', or rather we should just match
> args to the struct movable_operations e.g. dst, src?

Yeah, likely it should be made consistent. But not as part of this patch 
series :)

In particular, as we should be making all other things, like 
balloon_dev_info's migratepage and the ones implementing it use the same 
terminology in the same go.

On the TODO list.

> 
>>   {
>> -	struct balloon_dev_info *balloon = balloon_page_device(page);
>> +	struct balloon_dev_info *b_dev_info = balloon_page_device(page);
>> +	unsigned long flags;
>> +	int rc;
>>
>>   	VM_BUG_ON_PAGE(!PageLocked(page), page);
>>   	VM_BUG_ON_PAGE(!PageLocked(newpage), newpage);
>>
>>   	/* Isolated balloon pages cannot get deflated. */
> 
> Hmm, I'm a bit confused by this comment, isn't 'page' isolated?
> 
> This comment reads like !b_dev_info implies page isolated and thus a
> WARN_ON_ONCE() issue, but later you say 'Free the now-deflated page we isolated
> in balloon_page_isolate().' in reference to page?

The page is isolated, as documented for "struct movable_operations". And 
as the comment states, isolated pages cannot deflate.

So consequently, if we reach this point, we still have a balloon device, 
because the balloon device could not have deflated the page.

I don't really want to change the comment as part of this change here, 
it logically does not belong into this patch.

Maybe something for a cleanup patch:

"When we isolated the page, the page was inflated in a balloon device. 
As isolated balloon pages cannot get deflated, we still have a balloon 
device here."

> 
> So both can't be true.
> 
>> -	if (WARN_ON_ONCE(!balloon))
>> +	if (WARN_ON_ONCE(!b_dev_info))
>>   		return -EAGAIN;
>>
>> -	return balloon->migratepage(balloon, newpage, page, mode);
>> +	rc = b_dev_info->migratepage(b_dev_info, newpage, page, mode);
>> +	switch (rc) {
>> +	case 0:
>> +		spin_lock_irqsave(&b_dev_info->pages_lock, flags);
>> +
>> +		/* Insert the new page into the balloon list. */
> 
> Slightly weird to put this comment next to the pageref update then a newline
> hten the actual insertion bit.

When a page is in the list we have to grab a reference. No strong 
opinion about dropping the newline.

> 
>> +		get_page(newpage);
>> +
>> +		balloon_page_insert(b_dev_info, newpage);
>> +		__count_vm_event(BALLOON_MIGRATE);
>> +		break;
>> +	case -ENOENT:
>> +		spin_lock_irqsave(&b_dev_info->pages_lock, flags);
>> +
>> +		/* Old page was deflated but new page not inflated. */
> 
> Weird reference to old page and new page when old page is 'page', with dst, src
> we could just say destination/source?

I can strip the "Old" for now, but dst vs. src will be handled separately.

> 
>> +		__count_vm_event(BALLOON_DEFLATE);
>> +		break;
>> +	default:
>> +		return rc;
> 
> Don't we need to change the isolate stats etc. if we simply fail here? Or does
> the movable ops logic correctly handle this for us?

A non-0 return value from balloon_page_migrate() means that migration 
failed and that the (src) page stays isolated.

For example, migration core can later retry migration without re-isolation.

So the migration-core takes care of this.

> 
> Ah I guess baloon_page_putback() would be invoked :) Fun!

Right, the isolated page has to be putback later.

> 
>> +	}
> 
> It's subjective and pedantic but I don't love this use of the switch here, it
> really makes it seem like 'just another case' to do the _key_ action here of
> migrating a balloon page. Also could compress things a bit, that's even more
> subjective :)

You summarized my thoughts well ;)

I had exactly the thing you write below before I converted to switch. I 
didn't particularly like the filtering for return codes. Let me think 
about whether I want to go back.

As you note, it's highly subjective.
[...]

> 
>> +
>> +	b_dev_info->isolated_pages--;
>> +	spin_unlock_irqrestore(&b_dev_info->pages_lock, flags);
>> +
>> +	/* Free the now-deflated page we isolated in balloon_page_isolate(). */
>> +	balloon_page_finalize(page);
>> +	put_page(page);
> 
> OK so we get on migrate, but put the source page which would have got gotten
> previously I guess?

Right, the (old)/page source was deflated, so we prepare for handing it 
back to the buddy.

In the future, once these pages are frozen, migration-core will likely 
take care of doing the freeing, instead of us doing the put_page() here.

One goal of this patch set was to move the getting/putting of pages out 
as far as possible, such that the return values from 
isolate/migrate/putback later on indicate who now "owns" the reference 
to the frozen page.

Thanks for the review!

-- 
Cheers

David

Powered by blists - more mailing lists