Re: [PATCH v7 2/3] kho: fix deferred init of kho scratch

[Pratyush Yadav]

On Thu, Apr 09 2026, Mike Rapoport wrote:

> On Tue, Apr 07, 2026 at 12:21:56PM +0000, Pratyush Yadav wrote:
>> On Sun, Mar 22 2026, Mike Rapoport wrote:
>> 
>> > On Thu, Mar 19, 2026 at 07:17:48PM +0100, Michał Cłapiński wrote:
[...]
>> Can we just get rid of this entirely? And just update
>> memmap_init_zone_range() to also look for scratch and set the
>> migratetype correctly from the get go? That's more consistent IMO. The
>> two main places that initialize the struct page,
>> memmap_init_zone_range() and deferred_init_memmap_chunk(), check for
>> scratch and set the migratetype correctly.
>
> We could. E.g. let memmap_init() check the memblock flags and pass the
> migratetype to memmap_init_zone_range().
>
> I wanted to avoid as much KHO code in mm/ as possible, but if it is must
> have in deferred_init_memmap_chunk() we could add some to memmap_init() as
> well.

KHO fundamentally alters mm init, so I think it would be hard to keep it
to a neat corner unfortunately... We have been somewhat successful so
far, but that has come at the cost of performance. Once we start trying
to improve performance, I reckon more and more of it will spill into mm
init.

>  
>> > @@ -2061,12 +2060,15 @@ deferred_init_memmap_chunk(unsigned long start_pfn, unsigned long end_pfn,
>> >  		spfn = max(spfn, start_pfn);
>> >  		epfn = min(epfn, end_pfn);
>> >  
>> > +		if (memblock_is_kho_scratch_memory(PFN_PHYS(spfn)))
>> > +			mt = MIGRATE_CMA;
>> 
>> Would it make sense for for_each_free_mem_range() to also return the
>> flags for the region? Then you won't have to do another search. It adds
>> yet another parameter to it so no strong opinion, but something to
>> consider.
>
> I hesitated a lot about this.
> Have you seen memblock::__next_mem_range() signature? ;-)

Fair enough :-O

>
> I decided to start with something correct, but slowish and leave the churn
> and speed for later.

-- 
Regards,
Pratyush Yadav