All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mhocko@suse.com, linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-riscv@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, mpe@ellerman.id.au,
	linux@armlinux.org.uk, mingo@redhat.com, vbabka@suse.cz,
	rientjes@google.com, palmer@sifive.com, greentime@andestech.com,
	marc.zyngier@arm.com, rppt@linux.vnet.ibm.com,
	shakeelb@google.com, kirill@shutemov.name, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	robin.murphy@arm.com, aneesh.kumar@linux.ibm.com,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 12:53:54 +0000	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, linux-riscv@lists.infradead.org,
	linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, mpe@ellerman.id.au, tglx@linutronix.de,
	mingo@redhat.com, dave.hansen@linux.intel.com,
	peterz@infradead.org, christoffer.dall@arm.com,
	marc.zyngier@arm.com, kirill@shutemov.name,
	rppt@linux.vnet.ibm.com, mhocko@suse.com,
	ard.biesheuvel@linaro.org, mark.rutland@arm.com,
	steve.capper@arm.com, james.morse@arm.com, robin.murphy@arm.com,
	aneesh.kumar@linux.ibm.com, vbabka@suse.cz, shakeelb@google.com,
	rientjes@google.com, palmer@sifive.com, greentime@andestech.com
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 18:23:42 +0530	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mark.rutland@arm.com, mhocko@suse.com, linux-sh@vger.kernel.org,
	peterz@infradead.org, catalin.marinas@arm.com,
	dave.hansen@linux.intel.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org, kvmarm@lists.cs.columbia.edu,
	mpe@ellerman.id.au, linux@armlinux.org.uk, mingo@redhat.com,
	vbabka@suse.cz, rientjes@google.com, palmer@sifive.com,
	greentime@andestech.com, marc.zyngier@arm.com,
	rppt@linux.vnet.ibm.com, shakeelb@google.com,
	kirill@shutemov.name, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	robin.murphy@arm.com, steve.capper@arm.com,
	christoffer.dall@arm.com, james.morse@arm.com,
	aneesh.kumar@linux.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 18:23:42 +0530	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mark.rutland@arm.com, mhocko@suse.com, linux-sh@vger.kernel.org,
	peterz@infradead.org, catalin.marinas@arm.com,
	dave.hansen@linux.intel.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org, kvmarm@lists.cs.columbia.edu,
	linux@armlinux.org.uk, mingo@redhat.com, vbabka@suse.cz,
	rientjes@google.com, palmer@sifive.com, greentime@andestech.com,
	marc.zyngier@arm.com, rppt@linux.vnet.ibm.com,
	shakeelb@google.com, kirill@shutemov.name, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	robin.murphy@arm.com, steve.capper@arm.com,
	christoffer.dall@arm.com, james.morse@arm.com,
	aneesh.kumar@linux.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 18:23:42 +0530	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mhocko@suse.com, linux-sh@vger.kernel.org, peterz@infradead.org,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-riscv@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, mpe@ellerman.id.au,
	linux@armlinux.org.uk, mingo@redhat.com, vbabka@suse.cz,
	rientjes@google.com, palmer@sifive.com, greentime@andestech.com,
	marc.zyngier@arm.com, rppt@linux.vnet.ibm.com,
	shakeelb@google.com, kirill@shutemov.name, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	robin.murphy@arm.com, aneesh.kumar@linux.ibm.com,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 18:23:42 +0530	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: mark.rutland@arm.com, mhocko@suse.com, linux-sh@vger.kernel.org,
	peterz@infradead.org, catalin.marinas@arm.com,
	dave.hansen@linux.intel.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org, kvmarm@lists.cs.columbia.edu,
	mpe@ellerman.id.au, linux@armlinux.org.uk, mingo@redhat.com,
	vbabka@suse.cz, rientjes@google.com, palmer@sifive.com,
	greentime@andestech.com, marc.zyngier@arm.com,
	rppt@linux.vnet.ibm.com, shakeelb@google.com,
	kirill@shutemov.name, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org,
	robin.murphy@arm.com, steve.capper@arm.com,
	christoffer.dall@arm.com, james.morse@arm.com,
	aneesh.kumar@linux.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V2] mm: Introduce GFP_PGTABLE
Date: Wed, 16 Jan 2019 18:23:42 +0530	[thread overview]
Message-ID: <ddac2cef-43af-cda3-fe03-3fc070084731@arm.com> (raw)
In-Reply-To: <20190116065521.GC6643@rapoport-lnx>



On 01/16/2019 12:25 PM, Mike Rapoport wrote:
> On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages. This causes some
>> code duplication which can be easily avoided. GFP_KERNEL allocated and
>> cleared out pages (__GFP_ZERO) are required for page tables on any given
>> architecture. This creates a new generic GFP flag flag which can be used
>> for any page table page allocation. Does not cause any functional change.
>>
>> GFP_PGTABLE is being added into include/asm-generic/pgtable.h which is the
>> generic page tabe header just to prevent it's potential misuse as a general
>> allocation flag if included in include/linux/gfp.h.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Build tested on arm, arm64, powerpc, powerpc64le and x86.
>> Boot tested on arm64 and x86.
>>
>> Changes in V2:
>>
>> - Moved GFP_PGTABLE into include/asm-generic/pgtable.h
>> - On X86 added __GFP_ACCOUNT into GFP_PGTABLE at various places
>> - Replaced possible flags on riscv and nds32 with GFP_PGTABLE
>>
>> Original V1: https://lkml.org/lkml/2019/1/12/54 
>>
>>  arch/arm/include/asm/pgalloc.h               |  8 +++-----
>>  arch/arm/mm/mmu.c                            |  2 +-
>>  arch/arm64/include/asm/pgalloc.h             |  9 ++++-----
>>  arch/arm64/mm/mmu.c                          |  2 +-
>>  arch/arm64/mm/pgd.c                          |  4 ++--
>>  arch/nds32/include/asm/pgalloc.h             |  3 +--
>>  arch/powerpc/include/asm/book3s/64/pgalloc.h |  6 +++---
>>  arch/powerpc/include/asm/pgalloc.h           |  2 --
>>  arch/powerpc/kvm/book3s_64_mmu_hv.c          |  2 +-
>>  arch/powerpc/mm/pgtable-frag.c               |  4 ++--
>>  arch/riscv/include/asm/pgalloc.h             |  8 +++-----
>>  arch/sh/mm/pgtable.c                         |  6 ++----
>>  arch/unicore32/include/asm/pgalloc.h         |  6 ++----
>>  arch/x86/kernel/espfix_64.c                  |  6 ++----
>>  arch/x86/mm/pgtable.c                        | 15 +++++++--------
>>  include/asm-generic/pgtable.h                |  2 ++
>>  virt/kvm/arm/mmu.c                           |  2 +-
>>  17 files changed, 37 insertions(+), 50 deletions(-)
> I wonder, what about the other arches? Do they use different GFP flags?
>  

Some of them as listed below use (GFP_KERNEL | __GFP_ZERO) which I will fix
next time around. Some how was focused on removing PGALLOC_GFP that missed
the other ones.

arch/powerpc/include/asm/nohash/64/pgalloc.h
arch/alpha/include/asm/pgalloc.h
arch/alpha/mm/init.c
arch/csky/include/asm/pgalloc.h
arch/arc/include/asm/pgalloc.h
........
........

But then there are those which use GFP_KERNEL alone without __GFP_ZERO like
pmd_alloc_one() in arch/sparc/include/asm/pgalloc_64.h cannot be replaced
with this patch as it does not intend to change functionality.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-16 12:53 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16  6:21 [PATCH V2] mm: Introduce GFP_PGTABLE Anshuman Khandual
2019-01-16  6:33 ` Anshuman Khandual
2019-01-16  6:21 ` Anshuman Khandual
2019-01-16  6:21 ` Anshuman Khandual
2019-01-16  6:21 ` Anshuman Khandual
2019-01-16  6:55 ` Mike Rapoport
2019-01-16  6:55   ` Mike Rapoport
2019-01-16  6:55   ` Mike Rapoport
2019-01-16  6:55   ` Mike Rapoport
2019-01-16  6:55   ` Mike Rapoport
2019-01-16 12:53   ` Anshuman Khandual [this message]
2019-01-16 12:53     ` Anshuman Khandual
2019-01-16 12:53     ` Anshuman Khandual
2019-01-16 12:53     ` Anshuman Khandual
2019-01-16 12:53     ` Anshuman Khandual
2019-01-16 12:53     ` Anshuman Khandual
2019-01-16  6:57 ` Michal Hocko
2019-01-16  6:57   ` Michal Hocko
2019-01-16  6:57   ` Michal Hocko
2019-01-16  6:57   ` Michal Hocko
2019-01-16  6:57   ` Michal Hocko
2019-01-16 12:30   ` Matthew Wilcox
2019-01-16 12:30     ` Matthew Wilcox
2019-01-16 12:30     ` Matthew Wilcox
2019-01-16 12:30     ` Matthew Wilcox
2019-01-16 12:30     ` Matthew Wilcox
2019-01-16 12:30     ` Matthew Wilcox
2019-01-16 12:34     ` Peter Zijlstra
2019-01-16 12:34       ` Peter Zijlstra
2019-01-16 12:34       ` Peter Zijlstra
2019-01-16 12:34       ` Peter Zijlstra
2019-01-16 12:34       ` Peter Zijlstra
2019-01-16 12:34       ` Peter Zijlstra
2019-01-16 12:44     ` Michal Hocko
2019-01-16 12:44       ` Michal Hocko
2019-01-16 12:44       ` Michal Hocko
2019-01-16 12:44       ` Michal Hocko
2019-01-16 12:44       ` Michal Hocko
2019-01-16 12:44       ` Michal Hocko
2019-01-16 13:27       ` Anshuman Khandual
2019-01-16 13:39         ` Anshuman Khandual
2019-01-16 13:27         ` Anshuman Khandual
2019-01-16 13:27         ` Anshuman Khandual
2019-01-16 13:27         ` Anshuman Khandual
2019-01-16 13:36         ` Michal Hocko
2019-01-16 13:36           ` Michal Hocko
2019-01-16 13:36           ` Michal Hocko
2019-01-16 13:36           ` Michal Hocko
2019-01-16 13:36           ` Michal Hocko
2019-01-16 13:36           ` Michal Hocko
2019-01-16 13:12     ` Anshuman Khandual
2019-01-16 13:24       ` Anshuman Khandual
2019-01-16 13:12       ` Anshuman Khandual
2019-01-16 13:12       ` Anshuman Khandual
2019-01-16 13:12       ` Anshuman Khandual
2019-01-16 13:18       ` Matthew Wilcox
2019-01-16 13:18         ` Matthew Wilcox
2019-01-16 13:18         ` Matthew Wilcox
2019-01-16 13:18         ` Matthew Wilcox
2019-01-16 13:18         ` Matthew Wilcox
2019-01-16 13:18         ` Matthew Wilcox
2019-01-16 13:33         ` Michal Hocko
2019-01-16 13:33           ` Michal Hocko
2019-01-16 13:33           ` Michal Hocko
2019-01-16 13:33           ` Michal Hocko
2019-01-16 13:33           ` Michal Hocko
2019-01-16 13:33           ` Michal Hocko
2019-01-16 13:47         ` Christophe Leroy
2019-01-16 13:47           ` Christophe Leroy
2019-01-16 13:47           ` Christophe Leroy
2019-01-16 13:47           ` Christophe Leroy
2019-01-16 13:47           ` Christophe Leroy
2019-01-16 13:47           ` Christophe Leroy
2019-01-16 14:20           ` Matthew Wilcox
2019-01-16 14:20             ` Matthew Wilcox
2019-01-16 14:20             ` Matthew Wilcox
2019-01-16 14:20             ` Matthew Wilcox
2019-01-16 14:20             ` Matthew Wilcox
2019-01-17  9:56     ` Michael Ellerman
2019-01-17  9:56       ` Michael Ellerman
2019-01-17  9:56       ` Michael Ellerman
2019-01-17  9:56       ` Michael Ellerman
2019-01-17  9:56       ` Michael Ellerman
2019-01-17  9:56       ` Michael Ellerman
2019-01-16  7:10 ` Christophe Leroy
2019-01-16  7:10   ` Christophe Leroy
2019-01-16  7:10   ` Christophe Leroy
2019-01-16  7:10   ` Christophe Leroy
2019-01-16 12:39   ` Anshuman Khandual
2019-01-16 12:51     ` Anshuman Khandual
2019-01-16 12:39     ` Anshuman Khandual
2019-01-16 12:39     ` Anshuman Khandual

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=ddac2cef-43af-cda3-fe03-3fc070084731@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=greentime@andestech.com \
    --cc=kirill@shutemov.name \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=marc.zyngier@arm.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.com \
    --cc=rppt@linux.ibm.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=shakeelb@google.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=will.deacon@arm.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 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.