diff mbox series

[v3] arm64/mm: add fallback option to allocate virtually contiguous memory

Message ID d6c06f2ef39bbe6c715b2f6db76eb16155fdcee6.1602722808.git.sudaraja@codeaurora.org (mailing list archive)
State New, archived
Headers show
Series [v3] arm64/mm: add fallback option to allocate virtually contiguous memory | expand

Commit Message

Sudarshan Rajagopalan Oct. 15, 2020, 12:51 a.m. UTC 
When section mappings are enabled, we allocate vmemmap pages from
physically continuous memory of size PMD_SIZE using
vmemmap_alloc_block_buf(). Section mappings are good to reduce TLB
pressure. But when system is highly fragmented and memory blocks are
being hot-added at runtime, its possible that such physically continuous
memory allocations can fail. Rather than failing the memory hot-add
procedure, add a fallback option to allocate vmemmap pages from
discontinuous pages using vmemmap_populate_basepages().

Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Steven Price <steven.price@arm.com>
---
 arch/arm64/mm/mmu.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Comments

Will Deacon Oct. 15, 2020, 8:36 a.m. UTC | #1 
On Wed, Oct 14, 2020 at 05:51:23PM -0700, Sudarshan Rajagopalan wrote:
> When section mappings are enabled, we allocate vmemmap pages from
> physically continuous memory of size PMD_SIZE using
> vmemmap_alloc_block_buf(). Section mappings are good to reduce TLB
> pressure. But when system is highly fragmented and memory blocks are
> being hot-added at runtime, its possible that such physically continuous
> memory allocations can fail. Rather than failing the memory hot-add
> procedure, add a fallback option to allocate vmemmap pages from
> discontinuous pages using vmemmap_populate_basepages().
> 
> Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Steven Price <steven.price@arm.com>
> ---
>  arch/arm64/mm/mmu.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Please can you fix the subject? I have three copies of "PATCH v3" from
different days in my inbox. I know it sounds trivial, but getting these
little things right really helps with review, especially when it's sitting
amongst a sea of other patches.

Thanks,

Will
Sudarshan Rajagopalan Oct. 16, 2020, 6:49 p.m. UTC | #2 
On 2020-10-15 01:36, Will Deacon wrote:
> On Wed, Oct 14, 2020 at 05:51:23PM -0700, Sudarshan Rajagopalan wrote:
>> When section mappings are enabled, we allocate vmemmap pages from
>> physically continuous memory of size PMD_SIZE using
>> vmemmap_alloc_block_buf(). Section mappings are good to reduce TLB
>> pressure. But when system is highly fragmented and memory blocks are
>> being hot-added at runtime, its possible that such physically 
>> continuous
>> memory allocations can fail. Rather than failing the memory hot-add
>> procedure, add a fallback option to allocate vmemmap pages from
>> discontinuous pages using vmemmap_populate_basepages().
>> 
>> Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Logan Gunthorpe <logang@deltatee.com>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Steven Price <steven.price@arm.com>
>> ---
>>  arch/arm64/mm/mmu.c | 7 +++++--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> Please can you fix the subject? I have three copies of "PATCH v3" from
> different days in my inbox. I know it sounds trivial, but getting these
> little things right really helps with review, especially when it's 
> sitting
> amongst a sea of other patches.

Yes sure, sorry about that - will change it to "PATCH v4" to make it 
stand out from other patches.

> 
> Thanks,
> 
> Will


Sudarshan

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project
Sudarshan Rajagopalan Nov. 5, 2020, 12:03 a.m. UTC | #3 
On 2020-10-16 11:56, Sudarshan Rajagopalan wrote:

Hello Will, Catalin,

Did you have a chance to review this patch? It is reviewed by others and 
haven't seen any Nacks. This patch will be useful to have so that memory 
hotremove doesn't fail when such PMD_SIZE pages aren't available.. which 
is usually the case in low RAM devices.

> When section mappings are enabled, we allocate vmemmap pages from
> physically continuous memory of size PMD_SIZE using
> vmemmap_alloc_block_buf(). Section mappings are good to reduce TLB
> pressure. But when system is highly fragmented and memory blocks are
> being hot-added at runtime, its possible that such physically 
> continuous
> memory allocations can fail. Rather than failing the memory hot-add
> procedure, add a fallback option to allocate vmemmap pages from
> discontinuous pages using vmemmap_populate_basepages().
> 
> Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Steven Price <steven.price@arm.com>
> ---
>  arch/arm64/mm/mmu.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 75df62fea1b6..44486fd0e883 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1121,8 +1121,11 @@ int __meminit vmemmap_populate(unsigned long
> start, unsigned long end, int node,
>  			void *p = NULL;
> 
>  			p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> -			if (!p)
> -				return -ENOMEM;
> +			if (!p) {
> +				if (vmemmap_populate_basepages(addr, next, node, altmap))
> +					return -ENOMEM;
> +				continue;
> +			}
> 
>  			pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
>  		} else
Will Deacon Nov. 6, 2020, 1:43 p.m. UTC | #4 
On Fri, Oct 16, 2020 at 11:56:56AM -0700, Sudarshan Rajagopalan wrote:
> When section mappings are enabled, we allocate vmemmap pages from
> physically continuous memory of size PMD_SIZE using
> vmemmap_alloc_block_buf(). Section mappings are good to reduce TLB
> pressure. But when system is highly fragmented and memory blocks are
> being hot-added at runtime, its possible that such physically continuous
> memory allocations can fail. Rather than failing the memory hot-add
> procedure, add a fallback option to allocate vmemmap pages from
> discontinuous pages using vmemmap_populate_basepages().
> 
> Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Logan Gunthorpe <logang@deltatee.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Steven Price <steven.price@arm.com>
> ---
>  arch/arm64/mm/mmu.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 75df62fea1b6..44486fd0e883 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1121,8 +1121,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>  			void *p = NULL;
>  
>  			p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> -			if (!p)
> -				return -ENOMEM;
> +			if (!p) {
> +				if (vmemmap_populate_basepages(addr, next, node, altmap))
> +					return -ENOMEM;
> +				continue;
> +			}

Looks fine to me:

Acked-by: Will Deacon <will@kernel.org>

Will
Catalin Marinas Nov. 6, 2020, 2:38 p.m. UTC | #5 
On Wed, Nov 04, 2020 at 04:03:36PM -0800, Sudarshan Rajagopalan wrote:
> Did you have a chance to review this patch? It is reviewed by others and
> haven't seen any Nacks. This patch will be useful to have so that memory
> hotremove doesn't fail when such PMD_SIZE pages aren't available.. which is
> usually the case in low RAM devices.

Can you please post it again please with Will's ack? You posted a v4
which I think had the same message-id as v3. Mutt flagged it as
duplicate and I deleted it. Just to be sure (I'll queue it when we get
to -rc3).

Thanks.
diff mbox series

Patch

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 75df62fea1b6..44486fd0e883 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1121,8 +1121,11 @@  int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 			void *p = NULL;
 
 			p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
-			if (!p)
-				return -ENOMEM;
+			if (!p) {
+				if (vmemmap_populate_basepages(addr, next, node, altmap))
+					return -ENOMEM;
+				continue;
+			}
 
 			pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
 		} else