From: Randy Dunlap <rdunlap@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.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>,
Longpeng <longpeng2@huawei.com>, Will Deacon <will@kernel.org>,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing
Date: Wed, 18 Mar 2020 17:20:46 -0700 [thread overview]
Message-ID: <1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org> (raw)
In-Reply-To: <20200318220634.32100-5-mike.kravetz@oracle.com>
Hi Mike,
On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++
> mm/hugetlb.c | 78 +++++++++++++++-----
> 2 files changed, 87 insertions(+), 17 deletions(-)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line. The global
typo: command
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long long size;
Does any of this need to be updated? (from Documentation/admin-guide/kernel-parameters.txt)
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
--
~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.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>,
Vasily Gorbik <gor@linux.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Longpeng <longpeng2@huawei.com>, Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing
Date: Thu, 19 Mar 2020 00:20:46 +0000 [thread overview]
Message-ID: <1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org> (raw)
In-Reply-To: <20200318220634.32100-5-mike.kravetz@oracle.com>
Hi Mike,
On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++
> mm/hugetlb.c | 78 +++++++++++++++-----
> 2 files changed, 87 insertions(+), 17 deletions(-)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line. The global
typo: command
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long long size;
Does any of this need to be updated? (from Documentation/admin-guide/kernel-parameters.txt)
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
--
~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.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>,
Vasily Gorbik <gor@linux.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Longpeng <longpeng2@huawei.com>, Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing
Date: Wed, 18 Mar 2020 17:20:46 -0700 [thread overview]
Message-ID: <1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org> (raw)
In-Reply-To: <20200318220634.32100-5-mike.kravetz@oracle.com>
Hi Mike,
On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++
> mm/hugetlb.c | 78 +++++++++++++++-----
> 2 files changed, 87 insertions(+), 17 deletions(-)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line. The global
typo: command
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long long size;
Does any of this need to be updated? (from Documentation/admin-guide/kernel-parameters.txt)
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
--
~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.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>,
Vasily Gorbik <gor@linux.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Longpeng <longpeng2@huawei.com>, Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing
Date: Wed, 18 Mar 2020 17:20:46 -0700 [thread overview]
Message-ID: <1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org> (raw)
In-Reply-To: <20200318220634.32100-5-mike.kravetz@oracle.com>
Hi Mike,
On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++
> mm/hugetlb.c | 78 +++++++++++++++-----
> 2 files changed, 87 insertions(+), 17 deletions(-)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line. The global
typo: command
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long long size;
Does any of this need to be updated? (from Documentation/admin-guide/kernel-parameters.txt)
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
--
~Randy
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.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>,
Vasily Gorbik <gor@linux.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Paul Mackerras <paulus@samba.org>,
Andrew Morton <akpm@linux-foundation.org>,
Longpeng <longpeng2@huawei.com>, Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/4] hugetlbfs: clean up command line processing
Date: Wed, 18 Mar 2020 17:20:46 -0700 [thread overview]
Message-ID: <1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org> (raw)
In-Reply-To: <20200318220634.32100-5-mike.kravetz@oracle.com>
Hi Mike,
On 3/18/20 3:06 PM, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> Documentation/admin-guide/mm/hugetlbpage.rst | 26 +++++++
> mm/hugetlb.c | 78 +++++++++++++++-----
> 2 files changed, 87 insertions(+), 17 deletions(-)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cc85b4f156ca..2b9bf01db2b6 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3214,8 +3238,15 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the commnad line. The global
typo: command
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long long size;
Does any of this need to be updated? (from Documentation/admin-guide/kernel-parameters.txt)
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
multiple times interleaved with hugepages= to reserve
huge pages of different sizes. Valid pages sizes on
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
--
~Randy
_______________________________________________
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-19 0:21 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.)
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 [this message]
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=1820045d-0bf2-9a86-226d-e9c4d5928749@infradead.org \
--to=rdunlap@infradead.org \
--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@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=longpeng2@huawei.com \
--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.