[patch] mm: Ensure proper alignment for node_remap_start_pfn

Ravikiran G Thirumalai

author

2005-07-28 00:42 UTC #0 lore raw

PATCH 1/1 mm: Ensure proper alignment for node_remap_start_pfn

While reserving KVA for lmem_maps of node, we have to make sure that node_remap_start_pfn[] is aligned to a proper pmd boundary. (node_remap_start_pfn[] gets its value from node_end_pfn[])

Signed-off-by Ravikiran Thirumalai <[email protected]>

Signed-off-by Shai Fultheim <[email protected]>

arch/i386/mm/discontig.c +8 -0

Index: linux-2.6.13-rc3/arch/i386/mm/discontig.c
===================================================================
@@ -243,6 +243,14 @@
 		/* now the roundup is correct, convert to PAGE_SIZE pages */
 		size = size * PTRS_PER_PTE;
 
+		if (node_end_pfn[nid] & (PTRS_PER_PTE-1)) {
+			/* 
+			 * Adjust size if node_end_pfn is not on a proper 
+			 * pmd boundary. remap_numa_kva will barf otherwise.
+			 */
+			size +=  node_end_pfn[nid] & (PTRS_PER_PTE-1);
+		}
+
 		/*
 		 * Validate the region we are allocating only contains valid
 		 * pages.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrew Morton

2005-07-28 01:17 UTC #1 lore raw

Quoted 5 lines · Ravikiran G Thirumalai

While reserving KVA for lmem_maps of node, we have to make sure that node_remap_start_pfn[] is aligned to a proper pmd boundary. (node_remap_start_pfn[] gets its value from node_end_pfn[])

What are the effects of not having this patch applied? Does someone's computer crash, or what?

IOW: what problem is this fixing, precisely?

Quoted 10 lines

Index: linux-2.6.13-rc3/arch/i386/mm/discontig.c
===================================================================
arch/i386/mm/discontig.c +1 -0
@@ -243,6 +243,14 @@
 		/* now the roundup is correct, convert to PAGE_SIZE pages */
 		size = size * PTRS_PER_PTE;
 
+		if (node_end_pfn[nid] & (PTRS_PER_PTE-1)) {

arch/i386/mm/discontig.c line 256

Quoted 10 lines

arch/i386/mm/discontig.c +7 -0

+			/* 
+			 * Adjust size if node_end_pfn is not on a proper 
+			 * pmd boundary. remap_numa_kva will barf otherwise.
+			 */
+			size +=  node_end_pfn[nid] & (PTRS_PER_PTE-1);
+		}
+
 		/*
 		 * Validate the region we are allocating only contains valid
 		 * pages.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ravikiran G Thirumalai

author

2005-07-28 01:31 UTC #2 lore raw

Quoted 9 lines · Andrew Morton

Quoted 5 lines · Ravikiran G Thirumalai
While reserving KVA for lmem_maps of node, we have to make sure that node_remap_start_pfn[] is aligned to a proper pmd boundary. (node_remap_start_pfn[] gets its value from node_end_pfn[])
What are the effects of not having this patch applied? Does someone's computer crash, or what?

Yes, it does cause a crash.

Thanks,
Kiran
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Dave Hansen

2005-07-28 17:20 UTC #3 lore raw

Quoted 8 lines · Ravikiran G Thirumalai

Quoted 7 lines · Andrew Morton
Quoted 5 lines · Ravikiran G Thirumalai
While reserving KVA for lmem_maps of node, we have to make sure that node_remap_start_pfn[] is aligned to a proper pmd boundary. (node_remap_start_pfn[] gets its value from node_end_pfn[])

Quoted 4 lines

Quoted 2 lines
What are the effects of not having this patch applied? Does someone's computer crash, or what?
Yes, it does cause a crash.

I don't know of any NUMA x86 sub-arches that have nodes which are aligned on any less than 2MB. Is this an architecture that's supported in the tree, today?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ravikiran G Thirumalai

author

2005-07-28 18:14 UTC #4 lore raw

Quoted 9 lines · Dave Hansen

Quoted 4 lines · Ravikiran G Thirumalai
Quoted 2 lines · Andrew Morton
Quoted 1 line · Ravikiran G Thirumalai
Yes, it does cause a crash.
I don't know of any NUMA x86 sub-arches that have nodes which are aligned on any less than 2MB. Is this an architecture that's supported in the tree, today?

SRAT need not guarantee any alignment at all in the memory affinity
structure (the address in 64-bit byte address). And yes, there are x86-numa
machines that run the latest kernel tree and face this problem.

Thanks,
Kiran
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Dave Hansen

2005-07-28 18:25 UTC #5 lore raw

Quoted 2 lines · Ravikiran G Thirumalai

SRAT need not guarantee any alignment at all in the memory affinity structure (the address in 64-bit byte address)

The Summit machines (the only x86 user of the SRAT) have other hardware guarantees about alignment, so I guess that's why we've never encountered it. Are you using the SRAT on non-Summit hardware? That doesn't seem possible:

arch/i386/Kconfig:

        config ACPI_SRAT
                bool
                default y
                depends on NUMA && (X86_SUMMIT || X86_GENERICARCH)

Quoted 2 lines

And yes, there are x86-numa
machines that run the latest kernel tree and face this problem.

I didn't say "run the latest kernel tree". *In* the latest kernel tree :)

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>