Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma

[Rik van Riel <riel@surriel.com>]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Tue, 2020-03-10 at 11:05 -0700, Roman Gushchin wrote:
> On Tue, Mar 10, 2020 at 10:27:01AM -0700, Mike Kravetz wrote:
> > 
> > > +	for_each_node_state(nid, N_ONLINE) {
> > > +		unsigned long min_pfn = 0, max_pfn = 0;
> > > +
> > > +		for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn,
> > > NULL) {
> > > +			if (!min_pfn)
> > > +				min_pfn = start_pfn;
> > > +			max_pfn = end_pfn;
> > > +		}
> > > +
> > > +		res = cma_declare_contiguous(PFN_PHYS(min_pfn), size,
> > > +					     PFN_PHYS(max_pfn), (1UL <<
> > > 30),
> > 
> > The alignment is hard coded for x86 gigantic page size.  If this
> > supports
> > more architectures or becomes arch independent we will need to
> > determine
> > what this alignment should be.  Perhaps an arch specific call back
> > to get
> > the alignment for gigantic pages.  That will require a little
> > thought as
> > some arch's support multiple gigantic page sizes.
> 
> Good point!
> Should we take the biggest possible size as a reference?
> Or the smallest (larger than MAX_ORDER)?

I would say biggest.

You can always allocate multiple smaller gigantic pages
inside the space reserved for one ginormous one.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]