From: "Longpeng (Mike, Cloud Infrastructure Service Product Dept.)" <longpeng2@huawei.com>
To: Mike Kravetz <mike.kravetz@oracle.com>,
Dave Hansen <dave.hansen@intel.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linuxppc-dev@lists.ozlabs.org>,
<linux-riscv@lists.infradead.org>, <linux-s390@vger.kernel.org>,
<sparclinux@vger.kernel.org>, <linux-doc@vger.kernel.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Andrew Morton <akpm@linux-foundation.org>,
Vasily Gorbik <gor@linux.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
"David S.Miller" <davem@davemloft.net>
Subject: Re: [PATCH 1/4] hugetlbfs: add arch_hugetlb_valid_size
Date: Wed, 25 Mar 2020 10:58:46 +0800 [thread overview]
Message-ID: <5ea6313e-ec4f-a043-632b-ef2901ce2cc9@huawei.com> (raw)
In-Reply-To: <5aceea6a-8dc0-a44b-80c6-94511b5c75ca@oracle.com>
On 2020/3/19 6:52, Mike Kravetz wrote:
> On 3/18/20 3:15 PM, Dave Hansen wrote:
>> Hi Mike,
>>
>> The series looks like a great idea to me. One nit on the x86 bits,
>> though...
>>
>>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>>> index 5bfd5aef5378..51e6208fdeec 100644
>>> --- a/arch/x86/mm/hugetlbpage.c
>>> +++ b/arch/x86/mm/hugetlbpage.c
>>> @@ -181,16 +181,25 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
>>> #endif /* CONFIG_HUGETLB_PAGE */
>>>
>>> #ifdef CONFIG_X86_64
>>> +bool __init arch_hugetlb_valid_size(unsigned long long size)
>>> +{
>>> + if (size == PMD_SIZE)
>>> + return true;
>>> + else if (size == PUD_SIZE && boot_cpu_has(X86_FEATURE_GBPAGES))
>>> + return true;
>>> + else
>>> + return false;
>>> +}
>>
>> I'm pretty sure it's possible to have a system without 2M/PMD page
>> support. We even have a handy-dandy comment about it in
>> arch/x86/include/asm/required-features.h:
>>
>> #ifdef CONFIG_X86_64
>> #ifdef CONFIG_PARAVIRT
>> /* Paravirtualized systems may not have PSE or PGE available */
>> #define NEED_PSE 0
>> ...
>>
>> I *think* you need an X86_FEATURE_PSE check here to be totally correct.
>>
>> if (size == PMD_SIZE && cpu_feature_enabled(X86_FEATURE_PSE))
>> return true;
>>
>> BTW, I prefer cpu_feature_enabled() to boot_cpu_has() because it
>> includes disabled-features checking. I don't think any of it matters
>> for these specific features, but I generally prefer it on principle.
>
> Sounds good. I'll incorporate those changes into a v2, unless someone
> else with has a different opinion.
>
> BTW, this patch should not really change the way the code works today.
> It is mostly a movement of code. Unless I am missing something, the
> existing code will always allow setup of PMD_SIZE hugetlb pages.
>
Hi Mike,
Inspired by Dave's opinion, it seems the x86-specific hugepages_supported should
also need to use cpu_feature_enabled instead.
Also, I wonder if the hugepages_supported is correct ? There're two arch
specific hugepages_supported:
x86:
#define hugepages_supported() boot_cpu_has(X86_FEATURE_PSE)
and
s390:
#define hugepages_supported() (MACHINE_HAS_EDAT1)
Is it possible that x86 has X86_FEATURE_GBPAGES but hasn't X86_FEATURE_GBPAGES
or s390 has MACHINE_HAS_EDAT2 but hasn't MACHINE_HAS_EDAT1 ?
---
Regards,
Longpeng(Mike)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-25 2:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 22:06 [PATCH 0/4] Clean up hugetlb boot command line processing Mike Kravetz
2020-03-18 22:06 ` [PATCH 1/4] hugetlbfs: add arch_hugetlb_valid_size Mike Kravetz
2020-03-18 22:09 ` Will Deacon
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 23:36 ` Dave Hansen
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 23:10 ` Dave Hansen
2020-03-25 2:58 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.) [this message]
2020-03-25 9:38 ` Christian Borntraeger
2020-03-19 0:48 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 7:00 ` Christophe Leroy
2020-03-19 18:17 ` Mike Kravetz
2020-03-23 23:43 ` Mina Almasry
2020-03-18 22:06 ` [PATCH 2/4] hugetlbfs: move hugepagesz= parsing to arch independent code Mike Kravetz
2020-03-19 7:04 ` Christophe Leroy
2020-03-19 17:00 ` Mike Kravetz
2020-03-23 23:56 ` Mina Almasry
2020-03-18 22:06 ` [PATCH 3/4] hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate Mike Kravetz
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:23 ` Mina Almasry
2020-03-18 22:06 ` [PATCH 4/4] hugetlbfs: clean up command line processing Mike Kravetz
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 2:42 ` Mike Kravetz
2020-03-24 0:43 ` Mina Almasry
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-25 1:12 ` Mike Kravetz
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=5ea6313e-ec4f-a043-632b-ef2901ce2cc9@huawei.com \
--to=longpeng2@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paulus@samba.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/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).