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)
WARNING: multiple messages have this Message-ID (diff)
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: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
David S.Miller <davem@davemloft.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>
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)
WARNING: multiple messages have this Message-ID (diff)
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>,
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)
WARNING: multiple messages have this Message-ID (diff)
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: 152+ 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 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` [PATCH 1/4] hugetlbfs: add arch_hugetlb_valid_size Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:09 ` Will Deacon
2020-03-18 22:09 ` Will Deacon
2020-03-18 22:09 ` Will Deacon
2020-03-18 22:09 ` Will Deacon
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:38 ` Mike Kravetz
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:15 ` Dave Hansen
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 22:52 ` Mike Kravetz
2020-03-18 23:36 ` Dave Hansen
2020-03-18 23:36 ` Dave Hansen
2020-03-18 23:36 ` Dave Hansen
2020-03-18 23:36 ` Dave Hansen
2020-03-18 23:36 ` Dave Hansen
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 21:56 ` Mike Kravetz
2020-03-26 23:10 ` Dave Hansen
2020-03-26 23:10 ` Dave Hansen
2020-03-26 23:10 ` Dave Hansen
2020-03-26 23:10 ` Dave Hansen
2020-03-26 23:10 ` Dave Hansen
2020-03-25 2:58 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.) [this message]
2020-03-25 2:58 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-25 2:58 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-25 2:58 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-25 9:38 ` Christian Borntraeger
2020-03-25 9:38 ` Christian Borntraeger
2020-03-25 9:38 ` Christian Borntraeger
2020-03-25 9:38 ` Christian Borntraeger
2020-03-25 9:38 ` Christian Borntraeger
2020-03-25 9:38 ` Christian Borntraeger
2020-03-19 0:48 ` kbuild test robot
2020-03-19 0:48 ` kbuild test robot
2020-03-19 0:48 ` kbuild test robot
2020-03-19 0:48 ` kbuild test robot
2020-03-19 0:48 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 1:39 ` kbuild test robot
2020-03-19 7:00 ` Christophe Leroy
2020-03-19 7:00 ` Christophe Leroy
2020-03-19 7:00 ` Christophe Leroy
2020-03-19 7:00 ` Christophe Leroy
2020-03-19 18:17 ` Mike Kravetz
2020-03-19 18:17 ` Mike Kravetz
2020-03-19 18:17 ` Mike Kravetz
2020-03-19 18:17 ` Mike Kravetz
2020-03-23 23:43 ` Mina Almasry
2020-03-23 23:43 ` Mina Almasry
2020-03-23 23:43 ` Mina Almasry
2020-03-23 23:43 ` Mina Almasry
2020-03-23 23:43 ` Mina Almasry
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-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-19 7:04 ` Christophe Leroy
2020-03-19 7:04 ` Christophe Leroy
2020-03-19 7:04 ` Christophe Leroy
2020-03-19 7:04 ` Christophe Leroy
2020-03-19 17:00 ` Mike Kravetz
2020-03-19 17:00 ` Mike Kravetz
2020-03-19 17:00 ` Mike Kravetz
2020-03-19 17:00 ` Mike Kravetz
2020-03-23 23:56 ` Mina Almasry
2020-03-23 23:56 ` Mina Almasry
2020-03-23 23:56 ` Mina Almasry
2020-03-23 23:56 ` Mina Almasry
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-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:01 ` Mina Almasry
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:16 ` Mike Kravetz
2020-03-24 0:23 ` Mina Almasry
2020-03-24 0:23 ` Mina Almasry
2020-03-24 0:23 ` Mina Almasry
2020-03-24 0:23 ` Mina Almasry
2020-03-24 0:23 ` Mina Almasry
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-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-18 22:06 ` Mike Kravetz
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 0:20 ` Randy Dunlap
2020-03-19 2:42 ` Mike Kravetz
2020-03-19 2:42 ` Mike Kravetz
2020-03-19 2:42 ` Mike Kravetz
2020-03-19 2:42 ` Mike Kravetz
2020-03-19 2:42 ` Mike Kravetz
2020-03-24 0:43 ` Mina Almasry
2020-03-24 0:43 ` Mina Almasry
2020-03-24 0:43 ` Mina Almasry
2020-03-24 0:43 ` Mina Almasry
2020-03-24 0:43 ` Mina Almasry
2020-03-24 0:43 ` Mina Almasry
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-24 3:47 ` Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
2020-03-25 1:12 ` Mike Kravetz
2020-03-25 1:12 ` Mike Kravetz
2020-03-25 1:12 ` Mike Kravetz
2020-03-25 1:12 ` Mike Kravetz
2020-03-25 1:12 ` Mike Kravetz
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.