From: Alex Ghiti <alex@ghiti.fr>
To: Mike Kravetz <mike.kravetz@oracle.com>,
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: Sat, 12 Jan 2019 01:09:19 +0000 [thread overview]
Message-ID: <bc2059d2-0409-df2b-4c93-9438efa3043b@ghiti.fr> (raw)
In-Reply-To: <6e20f18c-0313-168e-ff86-f0bf3b90a46f@oracle.com>
On 1/10/19 6:28 PM, Mike Kravetz wrote:
> 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.
Ok, I understand now, I agree that we should allow non default huge
page allocation even if not explicitly specified on kernel command line
paramter. I'll add an __init function to init hstate for gigantic page.
Thanks Mike,
Alex
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-01-12 1:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 6:21 [PATCH 0/3] Hugetlbfs support for riscv Alexandre Ghiti
2018-12-10 6:21 ` [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel Alexandre Ghiti
2019-01-11 6:18 ` Paul Walmsley
2019-01-11 13:58 ` Alexandre Ghiti
2019-01-15 16:11 ` Christoph Hellwig
2019-01-15 18:52 ` Alex Ghiti
2018-12-10 6:21 ` [PATCH 2/3] riscv: Fix wrong comment about task size for riscv64 Alexandre Ghiti
2019-01-15 15:58 ` Christoph Hellwig
2019-01-15 18:53 ` Alex Ghiti
2019-02-07 12:52 ` Alexandre Ghiti
2018-12-10 6:21 ` [PATCH 3/3] riscv: Adjust mmap base address at a third of task size Alexandre Ghiti
2019-01-15 16:02 ` Christoph Hellwig
2019-01-15 18:54 ` Alex Ghiti
2019-01-25 19:02 ` Palmer Dabbelt
2019-01-26 9:23 ` Alex Ghiti
2019-01-27 16:57 ` Alex Ghiti
2019-01-28 11:17 ` Alexandre Ghiti
2019-01-07 17:57 ` [PATCH 0/3] Hugetlbfs support for riscv Alex Ghiti
2019-01-07 21:52 ` Paul Walmsley
2019-01-08 9:26 ` Alexandre Ghiti
2019-01-09 18:26 ` Palmer Dabbelt
2019-01-09 19:23 ` Mike Kravetz
2019-01-09 22:15 ` Palmer Dabbelt
2019-01-10 7:33 ` Alex Ghiti
2019-01-10 8:09 ` Alex Ghiti
2019-01-10 18:28 ` Mike Kravetz
2019-01-12 1:09 ` Alex Ghiti [this message]
2019-01-15 16:04 ` Christoph Hellwig
2019-01-15 18:56 ` Alex Ghiti
2019-01-15 19:25 ` Mike Kravetz
2019-01-15 20:52 ` Christoph Hellwig
2019-01-16 13:18 ` Alexandre Ghiti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc2059d2-0409-df2b-4c93-9438efa3043b@ghiti.fr \
--to=alex@ghiti.fr \
--cc=aghiti@upmem.com \
--cc=akpm@linux-foundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=catalin.marinas@arm.com \
--cc=linux-riscv@lists.infradead.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).