Re: [PATCH 4/6] x86/virt/tdx: Add extra memory to TDX module for the extensions

[Xu Yilun]

> > > What matters for fragmentation is not contiguity, it is how many
> > > pageblocks are left partially occupied by unmovable pages that are never
> > > freed.
> > > 
> > > So you can ask one pageblock at a time with
> > > 
> > > 	page = alloc_pages(GFP_KERNEL | __GFP_NOWARN, order);
> > > 
> > > with fallback to lower order if you must.
> > > 
> > > It also fits the ABI: pageblock_order is 9 on x86, i.e. 512 pages, which
> > > is exactly TDX_HPA_LIST_MAX_NR_PAGES. One allocation is one full HPA list
> > > is one TDH.EXT.MEM.ADD, so the allocation loop and the chunking loop
> > > become the same loop.
> > > 
> > > But alloc_contig_pages() might be a good enough approximation for
> > > per-pageblock allocation if we do it during the boot when fragmentation
> > > is low.
> > 
> > IIUC, you mean alloc_contig_pages() also gives good de-fragmentation
> > that we need. But it would be slightly easier to fail cause it requires
> > extra contiguity that we don't need.
> 
> alloc_contig_pages() can be more expensive than needed (or fail) since
> you ask for the full allocation size to be contiguous, where you should
> be okay with a set of pageblocks regardless where they are relative to
> each other.

I see.

> 
> > Multiple alloc_pages(order-9) meets our requirement exactly but the
> > falling back to lower order may create more fragments. And we can do
> > this because of the ABI definition - an HPA_LIST could happen to hold
> > an entire pageblock.
> > 
> > If I have to choose, I prefer alloc_contig_pages(). It doesn't have to
> > depend on HPA_LIST ABI details.
> 
> As I said before, as long as you do it once during the boot, it should
> be good enough.

Yes. Thanks for your detailed explanation!

> 
> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov