Skip to contentSkip to conversation

arm64/mm: add fallback option to allocate virtually

PATCH Superseded Sudarshan Rajagopalan 2 participants 4 messages Sep 30, 2020 – Oct 1, 2020 arm64

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore

Sudarshan Rajagopalan

author
#0 lore raw

PATCH v2 1/1 arm64/mm: add fallback option to allocate virtually

V1: The initial patch used the approach to abort at the first instance of PMD_SIZE allocation failure, unmaps all previously mapped sections using vmemmap_free and maps the entire request with vmemmap_populate_basepages to allocate virtually contiguous memory.
https://lkml.org/lkml/2020/9/10/66

V2: Allocates virtually contiguous memory only for sections that failed PMD_SIZE allocation, and continues to allocate physically contiguous memory for other sections.

Sudarshan Rajagopalan (1):
arm64/mm: add fallback option to allocate virtually contiguous memory

 arch/arm64/mm/mmu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#1 lore raw

PATCH v2 1/1 arm64/mm: add fallback option to allocate virtually contiguous memory

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 <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Anshuman Khandual <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Logan Gunthorpe <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Steven Price <[email protected]>
---
 arch/arm64/mm/mmu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/arm64/mm/mmu.c +12 -2
index 75df62f..9edbbb8 100644
@@ -1121,8 +1121,18 @@ 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 (altmap)
+					return -ENOMEM;	/* no fallback */
+
+				/*
+				 * fallback allocating with virtually
+				 * contiguous memory for this section
+				 */
+				if (vmemmap_populate_basepages(addr, next, node, NULL))
+					return -ENOMEM;
+				continue;
+			}
 
 			pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
 		} else
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
#2 lore raw

Re: [PATCH v2] arm64/mm: add fallback option to allocate virtually contiguous memory

Quoted 26 lines · Sudarshan Rajagopalan

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 <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Anshuman Khandual <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Logan Gunthorpe <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Steven Price <[email protected]>
---
 arch/arm64/mm/mmu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/arm64/mm/mmu.c +0 -0
index 75df62f..9edbbb8 100644

arch/arm64/mm/mmu.c int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, · line 1126

Quoted 8 lines
arch/arm64/mm/mmu.c +3 -2
@@ -1121,8 +1121,18 @@ 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 (altmap)
+					return -ENOMEM;	/* no fallback */

Why ? If huge pages inside a vmemmap section might have been allocated from altmap, the base page could also fallback on altmap. If this patch has just followed the existing x86 semantics, it was written [1] long back before vmemmap_populate_basepages() supported altmap allocation. While adding that support [2] recently, it was deliberate not to change x86 semantics as it was a platform decision. Nonetheless, it makes sense to fallback on altmap bases pages if and when required.

[1] 4b94ffdc4163 (x86, mm: introduce vmem_altmap to augment vmemmap_populate())
[2] 1d9cfee7535c (mm/sparsemem: enable vmem_altmap support in vmemmap_populate_basepages())

author
#3 lore raw

Re: [PATCH v2] arm64/mm: add fallback option to allocate virtually contiguous memory

Quoted 45 lines · Anshuman Khandual
Quoted 26 lines · Sudarshan Rajagopalan

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 <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Anshuman Khandual <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Logan Gunthorpe <[email protected]>
Cc David Hildenbrand <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Steven Price <[email protected]>
---
 arch/arm64/mm/mmu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/arm64/mm/mmu.c +0 -0
index 75df62f..9edbbb8 100644

arch/arm64/mm/mmu.c int __meminit vmemmap_populate(unsigned long · line 1127

Quoted 9 lines
arch/arm64/mm/mmu.c +3 -2
@@ -1121,8 +1121,18 @@ 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 (altmap)
+					return -ENOMEM;	/* no fallback */

Why ? If huge pages inside a vmemmap section might have been allocated from altmap, the base page could also fallback on altmap. If this patch has just followed the existing x86 semantics, it was written [1] long back before vmemmap_populate_basepages() supported altmap allocation. While adding that support [2] recently, it was deliberate not to change x86 semantics as it was a platform decision. Nonetheless, it makes sense to fallback on altmap bases pages if and when required.

Quoted 3 lines

[1] 4b94ffdc4163 (x86, mm: introduce vmem_altmap to augment vmemmap_populate())
[2] 1d9cfee7535c (mm/sparsemem: enable vmem_altmap support in vmemmap_populate_basepages())

Yes agreed. We can allow fallback on altmap as well. I did indeed follow x86 semantics. Will send the updated patch.

Sudarshan

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project