From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: 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,
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>, Longpeng <longpeng2@huawei.com>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Randy Dunlap <rdunlap@infradead.org>,
Mina Almasry <almasrymina@google.com>,
Peter Xu <peterx@redhat.com>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>
Subject: Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing
Date: Tue, 21 Apr 2020 16:02:01 +0200 [thread overview]
Message-ID: <20200421160201.0ddb9763@thinkpad> (raw)
In-Reply-To: <20200417185049.275845-1-mike.kravetz@oracle.com>
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> v3 -
> Used weak attribute method of defining arch_hugetlb_valid_size.
> This eliminates changes to arch specific hugetlb.h files (Peter)
> Updated documentation (Peter, Randy)
> Fixed handling of implicitly specified gigantic page preallocation
> in existing code and removed documentation of such. There is now
> no difference between handling of gigantic and non-gigantic pages.
> (Peter, Nitesh).
> This requires the most review as there is a small change to
> undocumented behavior. See patch 4 commit message for details.
> Added Acks and Reviews (Mina, Peter)
>
> v2 -
> Fix build errors with patch 1 (Will)
> Change arch_hugetlb_valid_size arg to unsigned long and remove
> irrelevant 'extern' keyword (Christophe)
> Documentation and other misc changes (Randy, Christophe, Mina)
> Do not process command line options if !hugepages_supported()
> (Dave, but it sounds like we may want to additional changes to
> hugepages_supported() for x86? If that is needed I would prefer
> a separate patch.)
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetlbfs evolved, updates to command line processing have been made to
> meet immediate needs and not necessarily in a coordinated manner. The result
> is that some processing is done in arch specific code, some is done in arch
> independent code and coordination is problematic. Semantics can vary between
> architectures.
>
> The patch series does the following:
> - Define arch specific arch_hugetlb_valid_size routine used to validate
> passed huge page sizes.
> - Move hugepagesz= command line parsing out of arch specific code and into
> an arch independent routine.
> - Clean up command line processing to follow desired semantics and
> document those semantics.
>
> [1] https://lore.kernel.org/linux-mm/20200305033014.1152-1-longpeng2@huawei.com
>
> Mike Kravetz (4):
> hugetlbfs: add arch_hugetlb_valid_size
> hugetlbfs: move hugepagesz= parsing to arch independent code
> hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
> hugetlbfs: clean up command line processing
>
> .../admin-guide/kernel-parameters.txt | 40 ++--
> Documentation/admin-guide/mm/hugetlbpage.rst | 35 ++++
> arch/arm64/mm/hugetlbpage.c | 30 +--
> arch/powerpc/mm/hugetlbpage.c | 30 +--
> arch/riscv/mm/hugetlbpage.c | 24 +--
> arch/s390/mm/hugetlbpage.c | 24 +--
> arch/sparc/mm/init_64.c | 43 +---
> arch/x86/mm/hugetlbpage.c | 23 +--
> include/linux/hugetlb.h | 2 +-
> mm/hugetlb.c | 190 +++++++++++++++---
> 10 files changed, 271 insertions(+), 170 deletions(-)
>
Looks good and works fine for s390, thanks for cleaning up!
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> # s390
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>,
Mina Almasry <almasrymina@google.com>,
linux-s390@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Longpeng <longpeng2@huawei.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Vasily Gorbik <gor@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing
Date: Tue, 21 Apr 2020 16:02:01 +0200 [thread overview]
Message-ID: <20200421160201.0ddb9763@thinkpad> (raw)
In-Reply-To: <20200417185049.275845-1-mike.kravetz@oracle.com>
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> v3 -
> Used weak attribute method of defining arch_hugetlb_valid_size.
> This eliminates changes to arch specific hugetlb.h files (Peter)
> Updated documentation (Peter, Randy)
> Fixed handling of implicitly specified gigantic page preallocation
> in existing code and removed documentation of such. There is now
> no difference between handling of gigantic and non-gigantic pages.
> (Peter, Nitesh).
> This requires the most review as there is a small change to
> undocumented behavior. See patch 4 commit message for details.
> Added Acks and Reviews (Mina, Peter)
>
> v2 -
> Fix build errors with patch 1 (Will)
> Change arch_hugetlb_valid_size arg to unsigned long and remove
> irrelevant 'extern' keyword (Christophe)
> Documentation and other misc changes (Randy, Christophe, Mina)
> Do not process command line options if !hugepages_supported()
> (Dave, but it sounds like we may want to additional changes to
> hugepages_supported() for x86? If that is needed I would prefer
> a separate patch.)
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetlbfs evolved, updates to command line processing have been made to
> meet immediate needs and not necessarily in a coordinated manner. The result
> is that some processing is done in arch specific code, some is done in arch
> independent code and coordination is problematic. Semantics can vary between
> architectures.
>
> The patch series does the following:
> - Define arch specific arch_hugetlb_valid_size routine used to validate
> passed huge page sizes.
> - Move hugepagesz= command line parsing out of arch specific code and into
> an arch independent routine.
> - Clean up command line processing to follow desired semantics and
> document those semantics.
>
> [1] https://lore.kernel.org/linux-mm/20200305033014.1152-1-longpeng2@huawei.com
>
> Mike Kravetz (4):
> hugetlbfs: add arch_hugetlb_valid_size
> hugetlbfs: move hugepagesz= parsing to arch independent code
> hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
> hugetlbfs: clean up command line processing
>
> .../admin-guide/kernel-parameters.txt | 40 ++--
> Documentation/admin-guide/mm/hugetlbpage.rst | 35 ++++
> arch/arm64/mm/hugetlbpage.c | 30 +--
> arch/powerpc/mm/hugetlbpage.c | 30 +--
> arch/riscv/mm/hugetlbpage.c | 24 +--
> arch/s390/mm/hugetlbpage.c | 24 +--
> arch/sparc/mm/init_64.c | 43 +---
> arch/x86/mm/hugetlbpage.c | 23 +--
> include/linux/hugetlb.h | 2 +-
> mm/hugetlb.c | 190 +++++++++++++++---
> 10 files changed, 271 insertions(+), 170 deletions(-)
>
Looks good and works fine for s390, thanks for cleaning up!
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> # s390
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>,
Mina Almasry <almasrymina@google.com>,
linux-s390@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Longpeng <longpeng2@huawei.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Vasily Gorbik <gor@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Nitesh Narayan Lal <nitesh@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing
Date: Tue, 21 Apr 2020 16:02:01 +0200 [thread overview]
Message-ID: <20200421160201.0ddb9763@thinkpad> (raw)
In-Reply-To: <20200417185049.275845-1-mike.kravetz@oracle.com>
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> v3 -
> Used weak attribute method of defining arch_hugetlb_valid_size.
> This eliminates changes to arch specific hugetlb.h files (Peter)
> Updated documentation (Peter, Randy)
> Fixed handling of implicitly specified gigantic page preallocation
> in existing code and removed documentation of such. There is now
> no difference between handling of gigantic and non-gigantic pages.
> (Peter, Nitesh).
> This requires the most review as there is a small change to
> undocumented behavior. See patch 4 commit message for details.
> Added Acks and Reviews (Mina, Peter)
>
> v2 -
> Fix build errors with patch 1 (Will)
> Change arch_hugetlb_valid_size arg to unsigned long and remove
> irrelevant 'extern' keyword (Christophe)
> Documentation and other misc changes (Randy, Christophe, Mina)
> Do not process command line options if !hugepages_supported()
> (Dave, but it sounds like we may want to additional changes to
> hugepages_supported() for x86? If that is needed I would prefer
> a separate patch.)
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetlbfs evolved, updates to command line processing have been made to
> meet immediate needs and not necessarily in a coordinated manner. The result
> is that some processing is done in arch specific code, some is done in arch
> independent code and coordination is problematic. Semantics can vary between
> architectures.
>
> The patch series does the following:
> - Define arch specific arch_hugetlb_valid_size routine used to validate
> passed huge page sizes.
> - Move hugepagesz= command line parsing out of arch specific code and into
> an arch independent routine.
> - Clean up command line processing to follow desired semantics and
> document those semantics.
>
> [1] https://lore.kernel.org/linux-mm/20200305033014.1152-1-longpeng2@huawei.com
>
> Mike Kravetz (4):
> hugetlbfs: add arch_hugetlb_valid_size
> hugetlbfs: move hugepagesz= parsing to arch independent code
> hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
> hugetlbfs: clean up command line processing
>
> .../admin-guide/kernel-parameters.txt | 40 ++--
> Documentation/admin-guide/mm/hugetlbpage.rst | 35 ++++
> arch/arm64/mm/hugetlbpage.c | 30 +--
> arch/powerpc/mm/hugetlbpage.c | 30 +--
> arch/riscv/mm/hugetlbpage.c | 24 +--
> arch/s390/mm/hugetlbpage.c | 24 +--
> arch/sparc/mm/init_64.c | 43 +---
> arch/x86/mm/hugetlbpage.c | 23 +--
> include/linux/hugetlb.h | 2 +-
> mm/hugetlb.c | 190 +++++++++++++++---
> 10 files changed, 271 insertions(+), 170 deletions(-)
>
Looks good and works fine for s390, thanks for cleaning up!
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> # s390
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>,
Mina Almasry <almasrymina@google.com>,
linux-s390@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Longpeng <longpeng2@huawei.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Vasily Gorbik <gor@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing
Date: Tue, 21 Apr 2020 14:02:01 +0000 [thread overview]
Message-ID: <20200421160201.0ddb9763@thinkpad> (raw)
In-Reply-To: <20200417185049.275845-1-mike.kravetz@oracle.com>
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> v3 -
> Used weak attribute method of defining arch_hugetlb_valid_size.
> This eliminates changes to arch specific hugetlb.h files (Peter)
> Updated documentation (Peter, Randy)
> Fixed handling of implicitly specified gigantic page preallocation
> in existing code and removed documentation of such. There is now
> no difference between handling of gigantic and non-gigantic pages.
> (Peter, Nitesh).
> This requires the most review as there is a small change to
> undocumented behavior. See patch 4 commit message for details.
> Added Acks and Reviews (Mina, Peter)
>
> v2 -
> Fix build errors with patch 1 (Will)
> Change arch_hugetlb_valid_size arg to unsigned long and remove
> irrelevant 'extern' keyword (Christophe)
> Documentation and other misc changes (Randy, Christophe, Mina)
> Do not process command line options if !hugepages_supported()
> (Dave, but it sounds like we may want to additional changes to
> hugepages_supported() for x86? If that is needed I would prefer
> a separate patch.)
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetlbfs evolved, updates to command line processing have been made to
> meet immediate needs and not necessarily in a coordinated manner. The result
> is that some processing is done in arch specific code, some is done in arch
> independent code and coordination is problematic. Semantics can vary between
> architectures.
>
> The patch series does the following:
> - Define arch specific arch_hugetlb_valid_size routine used to validate
> passed huge page sizes.
> - Move hugepagesz= command line parsing out of arch specific code and into
> an arch independent routine.
> - Clean up command line processing to follow desired semantics and
> document those semantics.
>
> [1] https://lore.kernel.org/linux-mm/20200305033014.1152-1-longpeng2@huawei.com
>
> Mike Kravetz (4):
> hugetlbfs: add arch_hugetlb_valid_size
> hugetlbfs: move hugepagesz= parsing to arch independent code
> hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
> hugetlbfs: clean up command line processing
>
> .../admin-guide/kernel-parameters.txt | 40 ++--
> Documentation/admin-guide/mm/hugetlbpage.rst | 35 ++++
> arch/arm64/mm/hugetlbpage.c | 30 +--
> arch/powerpc/mm/hugetlbpage.c | 30 +--
> arch/riscv/mm/hugetlbpage.c | 24 +--
> arch/s390/mm/hugetlbpage.c | 24 +--
> arch/sparc/mm/init_64.c | 43 +---
> arch/x86/mm/hugetlbpage.c | 23 +--
> include/linux/hugetlb.h | 2 +-
> mm/hugetlb.c | 190 +++++++++++++++---
> 10 files changed, 271 insertions(+), 170 deletions(-)
>
Looks good and works fine for s390, thanks for cleaning up!
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> # s390
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Xu <peterx@redhat.com>,
linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>,
Mina Almasry <almasrymina@google.com>,
linux-s390@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Longpeng <longpeng2@huawei.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Vasily Gorbik <gor@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Nitesh Narayan Lal <nitesh@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 0/4] Clean up hugetlb boot command line processing
Date: Tue, 21 Apr 2020 16:02:01 +0200 [thread overview]
Message-ID: <20200421160201.0ddb9763@thinkpad> (raw)
In-Reply-To: <20200417185049.275845-1-mike.kravetz@oracle.com>
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> v3 -
> Used weak attribute method of defining arch_hugetlb_valid_size.
> This eliminates changes to arch specific hugetlb.h files (Peter)
> Updated documentation (Peter, Randy)
> Fixed handling of implicitly specified gigantic page preallocation
> in existing code and removed documentation of such. There is now
> no difference between handling of gigantic and non-gigantic pages.
> (Peter, Nitesh).
> This requires the most review as there is a small change to
> undocumented behavior. See patch 4 commit message for details.
> Added Acks and Reviews (Mina, Peter)
>
> v2 -
> Fix build errors with patch 1 (Will)
> Change arch_hugetlb_valid_size arg to unsigned long and remove
> irrelevant 'extern' keyword (Christophe)
> Documentation and other misc changes (Randy, Christophe, Mina)
> Do not process command line options if !hugepages_supported()
> (Dave, but it sounds like we may want to additional changes to
> hugepages_supported() for x86? If that is needed I would prefer
> a separate patch.)
>
> Longpeng(Mike) reported a weird message from hugetlb command line processing
> and proposed a solution [1]. While the proposed patch does address the
> specific issue, there are other related issues in command line processing.
> As hugetlbfs evolved, updates to command line processing have been made to
> meet immediate needs and not necessarily in a coordinated manner. The result
> is that some processing is done in arch specific code, some is done in arch
> independent code and coordination is problematic. Semantics can vary between
> architectures.
>
> The patch series does the following:
> - Define arch specific arch_hugetlb_valid_size routine used to validate
> passed huge page sizes.
> - Move hugepagesz= command line parsing out of arch specific code and into
> an arch independent routine.
> - Clean up command line processing to follow desired semantics and
> document those semantics.
>
> [1] https://lore.kernel.org/linux-mm/20200305033014.1152-1-longpeng2@huawei.com
>
> Mike Kravetz (4):
> hugetlbfs: add arch_hugetlb_valid_size
> hugetlbfs: move hugepagesz= parsing to arch independent code
> hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
> hugetlbfs: clean up command line processing
>
> .../admin-guide/kernel-parameters.txt | 40 ++--
> Documentation/admin-guide/mm/hugetlbpage.rst | 35 ++++
> arch/arm64/mm/hugetlbpage.c | 30 +--
> arch/powerpc/mm/hugetlbpage.c | 30 +--
> arch/riscv/mm/hugetlbpage.c | 24 +--
> arch/s390/mm/hugetlbpage.c | 24 +--
> arch/sparc/mm/init_64.c | 43 +---
> arch/x86/mm/hugetlbpage.c | 23 +--
> include/linux/hugetlb.h | 2 +-
> mm/hugetlb.c | 190 +++++++++++++++---
> 10 files changed, 271 insertions(+), 170 deletions(-)
>
Looks good and works fine for s390, thanks for cleaning up!
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> # s390
_______________________________________________
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-04-21 14:02 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 18:50 [PATCH v3 0/4] Clean up hugetlb boot command line processing Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` [PATCH v3 1/4] hugetlbfs: add arch_hugetlb_valid_size Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` [PATCH v3 2/4] hugetlbfs: move hugepagesz= parsing to arch independent code Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-27 5:04 ` Sandipan Das
2020-04-27 5:16 ` Sandipan Das
2020-04-27 5:04 ` Sandipan Das
2020-04-27 5:04 ` Sandipan Das
2020-04-27 5:04 ` Sandipan Das
2020-04-27 17:25 ` Mike Kravetz
2020-04-27 17:25 ` Mike Kravetz
2020-04-27 17:25 ` Mike Kravetz
2020-04-27 17:25 ` Mike Kravetz
2020-04-27 17:25 ` Mike Kravetz
2020-04-27 19:09 ` Mike Kravetz
2020-04-27 19:09 ` Mike Kravetz
2020-04-27 19:09 ` Mike Kravetz
2020-04-27 19:09 ` Mike Kravetz
2020-04-27 19:09 ` Mike Kravetz
2020-04-27 20:18 ` Andrew Morton
2020-04-27 20:18 ` Andrew Morton
2020-04-27 20:18 ` Andrew Morton
2020-04-27 20:18 ` Andrew Morton
2020-04-27 20:18 ` Andrew Morton
2020-04-27 20:31 ` Mike Kravetz
2020-04-27 20:31 ` Mike Kravetz
2020-04-27 20:31 ` Mike Kravetz
2020-04-27 20:31 ` Mike Kravetz
2020-04-27 20:31 ` Mike Kravetz
2020-04-28 4:17 ` Sandipan Das
2020-04-28 4:29 ` Sandipan Das
2020-04-28 4:17 ` Sandipan Das
2020-04-28 4:17 ` Sandipan Das
2020-04-28 4:17 ` Sandipan Das
2020-04-17 18:50 ` [PATCH v3 3/4] hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-20 19:41 ` Anders Roxell
2020-04-20 19:41 ` Anders Roxell
2020-04-20 19:41 ` Anders Roxell
2020-04-20 19:41 ` Anders Roxell
2020-04-20 19:41 ` Anders Roxell
2020-04-22 10:42 ` Aneesh Kumar K.V
2020-04-22 10:54 ` Aneesh Kumar K.V
2020-04-22 10:42 ` Aneesh Kumar K.V
2020-04-22 10:42 ` Aneesh Kumar K.V
2020-04-22 10:42 ` Aneesh Kumar K.V
2020-04-22 10:42 ` Aneesh Kumar K.V
2020-04-22 16:56 ` Mike Kravetz
2020-04-22 16:56 ` Mike Kravetz
2020-04-22 16:56 ` Mike Kravetz
2020-04-22 16:56 ` Mike Kravetz
2020-04-22 16:56 ` Mike Kravetz
2020-04-17 18:50 ` [PATCH v3 4/4] hugetlbfs: clean up command line processing Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-17 18:50 ` Mike Kravetz
2020-04-20 15:34 ` [PATCH v3 0/4] Clean up hugetlb boot " Qian Cai
2020-04-20 15:34 ` Qian Cai
2020-04-20 15:34 ` Qian Cai
2020-04-20 15:34 ` Qian Cai
2020-04-20 15:34 ` Qian Cai
2020-04-20 18:20 ` Mike Kravetz
2020-04-20 18:20 ` Mike Kravetz
2020-04-20 18:20 ` Mike Kravetz
2020-04-20 18:20 ` Mike Kravetz
2020-04-20 18:20 ` Mike Kravetz
2020-04-20 19:45 ` Will Deacon
2020-04-20 19:45 ` Will Deacon
2020-04-20 19:45 ` Will Deacon
2020-04-20 19:45 ` Will Deacon
2020-04-20 19:45 ` Will Deacon
2020-04-20 20:29 ` Anders Roxell
2020-04-20 20:29 ` Anders Roxell
2020-04-20 20:29 ` Anders Roxell
2020-04-20 20:29 ` Anders Roxell
2020-04-20 20:29 ` Anders Roxell
2020-04-20 21:40 ` Mike Kravetz
2020-04-20 21:40 ` Mike Kravetz
2020-04-20 21:40 ` Mike Kravetz
2020-04-20 21:40 ` Mike Kravetz
2020-04-20 21:40 ` Mike Kravetz
2020-04-20 22:53 ` Anders Roxell
2020-04-20 22:53 ` Anders Roxell
2020-04-20 22:53 ` Anders Roxell
2020-04-20 22:53 ` Anders Roxell
2020-04-20 22:53 ` Anders Roxell
2020-04-22 21:54 ` Casey Cairn
2020-04-22 21:54 ` Casey Cairn
2020-04-21 6:58 ` Will Deacon
2020-04-21 6:58 ` Will Deacon
2020-04-21 6:58 ` Will Deacon
2020-04-21 6:58 ` Will Deacon
2020-04-21 6:58 ` Will Deacon
2020-04-21 14:02 ` Gerald Schaefer [this message]
2020-04-21 14:02 ` Gerald Schaefer
2020-04-21 14:02 ` Gerald Schaefer
2020-04-21 14:02 ` Gerald Schaefer
2020-04-21 14:02 ` Gerald Schaefer
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=20200421160201.0ddb9763@thinkpad \
--to=gerald.schaefer@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@c-s.fr \
--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=nitesh@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paulus@samba.org \
--cc=peterx@redhat.com \
--cc=rdunlap@infradead.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.