Re: [PATCH 0/3] Hugetlbfs support for riscv

From: Mike Kravetz <mike.kravetz@oracle.com>
To: Alex Ghiti <alex@ghiti.fr>, Alexandre Ghiti <aghiti@upmem.com>,
	palmer@sifive.com
Cc: aou@eecs.berkeley.edu, catalin.marinas@arm.com,
	ndesaulniers@google.com, mingo@kernel.org, atish.patra@wdc.com,
	linux-riscv@lists.infradead.org, akpm@linux-foundation.org
Subject: Re: [PATCH 0/3] Hugetlbfs support for riscv
Date: Thu, 10 Jan 2019 10:28:34 -0800	[thread overview]
Message-ID: <6e20f18c-0313-168e-ff86-f0bf3b90a46f@oracle.com> (raw)
In-Reply-To: <6c5bccf0-f185-4db4-96fc-5439bf8f6330@ghiti.fr>

On 1/10/19 12:09 AM, Alex Ghiti wrote:
> On 1/9/19 7:23 PM, Mike Kravetz wrote:
>> On 12/9/18 10:21 PM, Alexandre Ghiti wrote:
>>> However I don't see any strong dependency between free_contig_range
>>> and those configs, maybe we could allow hugetlbfs users to free boot
>>> reserved hugepages without those configs activated, I will propose
>>> something if Mike Kravetz agrees.
>> Yes, that should be modified.  I think it would be a simple matter of moving
>> free_contig_range out of that ifdef block.  If you would like, I can submit
>> a patch for that.
> 
> 
> I think there is more to do: free_gigantic_page is only defined with
> ARCH_HAS_GIGANTIC_PAGE which in turn is only defined with
> CMA || (MEMORY_ISOLATION && COMPACTION). Moreover, if
> ARCH_HAS_GIGANTIC_PAGE is not defined, gigantic_page_supported
> will return false and then function like update_and_free_page will
> not reach the call to free_gigantic_page...etc. I will send you a patch
> when I have fixed all of that :)

Yes, I spoke too soon :)

>> Somewhat related, I do not think your patches enable dynamic allocation of
>> gigantic pages.  Not sure if that was an oversight or conscious decision.
>> I am not sure this is a highly used feature, but if you can do it on riscv
>> then why not?
> 
> I'm not sure to understand: do you mean picking an already allocated
> gigantic page or really allocating it with alloc_gigantic_page ? Or
> something else ?

The term 'dynamic allocation' may not be accurate.  Sorry!

Yes, I was talking about really allocating with alloc_gigantic_page.
It is possible to do this as long as the hstate for the gigantic page
size already exists.  If nothing is specified on the kernel boot command
line, the arch independent code will only set up the hstate for the default
huge page size.  x86 has this at the end of hugetlbpage.c to create the
gigantic page hstate as along as all config options are specified.

#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) ||
defined(CONFIG_CMA)
static __init int gigantic_pages_init(void)
{
	/* With compaction or CMA we can allocate gigantic pages at runtime */
	if (boot_cpu_has(X86_FEATURE_GBPAGES) && !size_to_hstate(1UL << PUD_SHIFT))
		hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
	return 0;
}
arch_initcall(gigantic_pages_init);
#endif

I believe some other architectures do something similar to automatically
set up hstates other huge pages sizes at boot time.  Totally optional,
but you might want to do something like this for riscv.

-- 
Mike Kravetz

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv