x86: numa 32 using apicid_2_node to get node for logical_apicid

PATCH New Yinghai Lu 5 participants 17 messages Jun 25, 2008 – Jun 26, 2008

Subsystems (4)

x86 PCI x86 MM Hibernation

lore

Share & tools

lore

Yinghai Lu

author

2008-06-25 05:13 UTC #0 lore raw

PATCH 1/1 x86: numa 32 using apicid_2_node to get node for logical_apicid

Signed-off-by Yinghai Lu <[email protected]>

---
 include/asm-x86/mach-bigsmp/mach_apic.h  |    2 +-
 include/asm-x86/mach-default/mach_apic.h |    4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

include/asm-x86/mach-bigsmp/mach_apic.h +1 -1

Index: linux-2.6/include/asm-x86/mach-bigsmp/mach_apic.h
===================================================================
@@ -81,7 +81,7 @@ static inline int multi_timer_check(int 
 
 static inline int apicid_to_node(int logical_apicid)
 {
-	return (0);
+	return apicid_2_node[hard_smp_processor_id()];
 }
 
 static inline int cpu_present_to_apicid(int mps_cpu)

include/asm-x86/mach-default/mach_apic.h +4 -0

Index: linux-2.6/include/asm-x86/mach-default/mach_apic.h
===================================================================
@@ -77,7 +77,11 @@ static inline void setup_apic_routing(vo
 
 static inline int apicid_to_node(int logical_apicid)
 {
+#ifdef CONFIG_SMP
+	return apicid_2_node[hard_smp_processor_id()];
+#else
 	return 0;
+#endif
 }
 #endif

Yinghai Lu

author

2008-06-25 05:13 UTC #1 lore raw

PATCH 1/1 x86: remove end_pfn in 64bit

and use max_pfn directly.

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/kernel/aperture_64.c      |    6 ++++--
 arch/x86/kernel/e820.c             |    2 +-
 arch/x86/kernel/early-quirks.c     |    2 +-
 arch/x86/kernel/machine_kexec_64.c |    2 +-
 arch/x86/kernel/pci-calgary_64.c   |    4 ++--
 arch/x86/kernel/pci-dma.c          |    4 ++--
 arch/x86/kernel/pci-gart_64.c      |    4 ++--
 arch/x86/kernel/pci-swiotlb_64.c   |    2 +-
 arch/x86/kernel/setup_64.c         |   21 ++++++++++-----------
 arch/x86/mm/init_64.c              |   17 ++++++-----------
 arch/x86/mm/k8topology_64.c        |    4 ++--
 arch/x86/mm/numa_64.c              |    4 ++--
 arch/x86/mm/srat_64.c              |    2 +-
 arch/x86/power/hibernate_64.c      |    2 +-
 include/asm-x86/page_64.h          |    5 +++--
 15 files changed, 39 insertions(+), 42 deletions(-)

arch/x86/kernel/aperture_64.c +4 -2

Index: linux-2.6/arch/x86/kernel/aperture_64.c
===================================================================
@@ -407,7 +407,9 @@ void __init gart_iommu_hole_init(void)
 				    agp_aper_base == aper_base &&
 				    agp_aper_order == aper_order) {
 					/* the same between two setting from NB and agp */
-					if (!no_iommu && end_pfn > MAX_DMA32_PFN && !printed_gart_size_msg) {
+					if (!no_iommu &&
+					    max_pfn > MAX_DMA32_PFN &&
+					    !printed_gart_size_msg) {
 						printk(KERN_ERR "you are using iommu with agp, but GART size is less than 64M\n");
 						printk(KERN_ERR "please increase GART size in your BIOS setup\n");
 						printk(KERN_ERR "if BIOS doesn't have that option, contact your HW vendor!\n");

@@ -448,7 +450,7 @@ out:
 		/* Got the aperture from the AGP bridge */
 	} else if (swiotlb && !valid_agp) {
 		/* Do nothing */
-	} else if ((!no_iommu && end_pfn > MAX_DMA32_PFN) ||
+	} else if ((!no_iommu && max_pfn > MAX_DMA32_PFN) ||
 		   force_iommu ||
 		   valid_agp ||
 		   fallback_aper_force) {

arch/x86/kernel/e820.c +1 -1

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
@@ -527,7 +527,7 @@ __init void e820_setup_gap(void)
 
 #ifdef CONFIG_X86_64
 	if (!found) {
-		gapstart = (end_pfn << PAGE_SHIFT) + 1024*1024;
+		gapstart = (max_pfn << PAGE_SHIFT) + 1024*1024;
 		printk(KERN_ERR "PCI: Warning: Cannot find a gap in the 32bit "
 		       "address range\n"
 		       KERN_ERR "PCI: Unassigned devices with 32bit resource "

arch/x86/kernel/early-quirks.c +1 -1

Index: linux-2.6/arch/x86/kernel/early-quirks.c
===================================================================
@@ -50,7 +50,7 @@ static void __init fix_hypertransport_co
 static void __init via_bugs(int  num, int slot, int func)
 {
 #ifdef CONFIG_GART_IOMMU
-	if ((end_pfn > MAX_DMA32_PFN ||  force_iommu) &&
+	if ((max_pfn > MAX_DMA32_PFN ||  force_iommu) &&
 	    !gart_iommu_aperture_allowed) {
 		printk(KERN_INFO
 		       "Looks like a VIA chipset. Disabling IOMMU."

arch/x86/kernel/machine_kexec_64.c +1 -1

Index: linux-2.6/arch/x86/kernel/machine_kexec_64.c
===================================================================
@@ -112,7 +112,7 @@ static int init_pgtable(struct kimage *i
 {
 	pgd_t *level4p;
 	level4p = (pgd_t *)__va(start_pgtable);
- 	return init_level4_page(image, level4p, 0, end_pfn << PAGE_SHIFT);
+	return init_level4_page(image, level4p, 0, max_pfn << PAGE_SHIFT);
 }
 
 static void set_idt(void *newidt, u16 limit)

arch/x86/kernel/pci-calgary_64.c +2 -2

Index: linux-2.6/arch/x86/kernel/pci-calgary_64.c
===================================================================
@@ -1394,7 +1394,7 @@ void __init detect_calgary(void)
 		return;
 	}
 
-	specified_table_size = determine_tce_table_size(end_pfn * PAGE_SIZE);
+	specified_table_size = determine_tce_table_size(max_pfn * PAGE_SIZE);
 
 	for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) {
 		struct calgary_bus_info *info = &bus_info[bus];

@@ -1459,7 +1459,7 @@ int __init calgary_iommu_init(void)
 	if (ret) {
 		printk(KERN_ERR "PCI-DMA: Calgary init failed %d, "
 		       "falling back to no_iommu\n", ret);
-		if (end_pfn > MAX_DMA32_PFN)
+		if (max_pfn > MAX_DMA32_PFN)
 			printk(KERN_ERR "WARNING more than 4GB of memory, "
 					"32bit PCI may malfunction.\n");
 		return ret;

arch/x86/kernel/pci-dma.c +2 -2

Index: linux-2.6/arch/x86/kernel/pci-dma.c
===================================================================
@@ -74,7 +74,7 @@ early_param("dma32_size", parse_dma32_si
 void __init dma32_reserve_bootmem(void)
 {
 	unsigned long size, align;
-	if (end_pfn <= MAX_DMA32_PFN)
+	if (max_pfn <= MAX_DMA32_PFN)
 		return;
 
 	/*

@@ -93,7 +93,7 @@ void __init dma32_reserve_bootmem(void)
 static void __init dma32_free_bootmem(void)
 {
 
-	if (end_pfn <= MAX_DMA32_PFN)
+	if (max_pfn <= MAX_DMA32_PFN)
 		return;
 
 	if (!dma32_bootmem_ptr)

arch/x86/kernel/pci-gart_64.c +2 -2

Index: linux-2.6/arch/x86/kernel/pci-gart_64.c
===================================================================
@@ -752,10 +752,10 @@ void __init gart_iommu_init(void)
 		return;
 
 	if (no_iommu ||
-	    (!force_iommu && end_pfn <= MAX_DMA32_PFN) ||
+	    (!force_iommu && max_pfn <= MAX_DMA32_PFN) ||
 	    !gart_iommu_aperture ||
 	    (no_agp && init_k8_gatt(&info) < 0)) {
-		if (end_pfn > MAX_DMA32_PFN) {
+		if (max_pfn > MAX_DMA32_PFN) {
 			printk(KERN_WARNING "More than 4GB of memory "
 			       	          "but GART IOMMU not available.\n"
 			       KERN_WARNING "falling back to iommu=soft.\n");

arch/x86/kernel/pci-swiotlb_64.c +1 -1

Index: linux-2.6/arch/x86/kernel/pci-swiotlb_64.c
===================================================================
@@ -38,7 +38,7 @@ const struct dma_mapping_ops swiotlb_dma
 void __init pci_swiotlb_init(void)
 {
 	/* don't initialize swiotlb if iommu=off (no_iommu=1) */
-	if (!iommu_detected && !no_iommu && end_pfn > MAX_DMA32_PFN)
+	if (!iommu_detected && !no_iommu && max_pfn > MAX_DMA32_PFN)
 	       swiotlb = 1;
 	if (swiotlb_force)
 		swiotlb = 1;

arch/x86/kernel/setup_64.c +10 ~~-11~~

Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================
@@ -161,7 +161,7 @@ static void __init reserve_initrd(void)
 		unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
 		unsigned long ramdisk_size  = boot_params.hdr.ramdisk_size;
 		unsigned long ramdisk_end   = ramdisk_image + ramdisk_size;
-		unsigned long end_of_mem    = end_pfn << PAGE_SHIFT;
+		unsigned long end_of_mem    = max_pfn << PAGE_SHIFT;
 
 		if (ramdisk_end <= end_of_mem) {
 			/*

@@ -270,25 +270,25 @@ void __init setup_arch(char **cmdline_p)
 	 * partially used pages are not usable - thus
 	 * we are rounding upwards:
 	 */
-	end_pfn = e820_end_of_ram();
+	max_pfn = e820_end_of_ram();
 
 	/* pre allocte 4k for mptable mpc */
 	early_reserve_e820_mpc_new();
 	/* update e820 for memory not covered by WB MTRRs */
 	mtrr_bp_init();
-	if (mtrr_trim_uncached_memory(end_pfn)) {
+	if (mtrr_trim_uncached_memory(max_pfn)) {
 		remove_all_active_ranges();
 		e820_register_active_regions(0, 0, -1UL);
-		end_pfn = e820_end_of_ram();
+		max_pfn = e820_end_of_ram();
 	}
 
 	reserve_initrd();
 
-	num_physpages = end_pfn;
+	num_physpages = max_pfn;
 
 	check_efer();
 
-	max_pfn_mapped = init_memory_mapping(0, (end_pfn << PAGE_SHIFT));
+	max_pfn_mapped = init_memory_mapping(0, (max_pfn << PAGE_SHIFT));
 
 	vsmp_init();

@@ -303,9 +303,8 @@ void __init setup_arch(char **cmdline_p)
 	acpi_boot_table_init();
 
 	/* How many end-of-memory variables you have, grandma! */
-	max_low_pfn = end_pfn;
-	max_pfn = end_pfn;
-	high_memory = (void *)__va(end_pfn * PAGE_SIZE - 1) + 1;
+	max_low_pfn = max_pfn;
+	high_memory = (void *)__va(max_pfn * PAGE_SIZE - 1) + 1;
 
 	/* Remove active ranges so rediscovery with NUMA-awareness happens */
 	remove_all_active_ranges();

@@ -317,7 +316,7 @@ void __init setup_arch(char **cmdline_p)
 	acpi_numa_init();
 #endif
 
-	initmem_init(0, end_pfn);
+	initmem_init(0, max_pfn);
 
 	dma32_reserve_bootmem();

@@ -369,7 +368,7 @@ void __init setup_arch(char **cmdline_p)
 	 * We trust e820 completely. No explicit ROM probing in memory.
 	 */
 	e820_reserve_resources();
-	e820_mark_nosave_regions(end_pfn);
+	e820_mark_nosave_regions(max_pfn);
 
 	reserve_standard_io_resources();

arch/x86/mm/init_64.c +6 ~~-11~~

Index: linux-2.6/arch/x86/mm/init_64.c
===================================================================
@@ -49,11 +49,6 @@
 #include <asm/cacheflush.h>
 
 /*
- * PFN of last memory page.
- */
-unsigned long end_pfn;
-
-/*
  * end_pfn only includes RAM, while max_pfn_mapped includes all e820 entries.
  * The direct mapping extends to max_pfn_mapped, so that we can directly access
  * apertures, ACPI and other tables without having to play with fixmaps.

@@ -650,9 +645,9 @@ void __init paging_init(void)
 	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
 	max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
 	max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
-	max_zone_pfns[ZONE_NORMAL] = end_pfn;
+	max_zone_pfns[ZONE_NORMAL] = max_pfn;
 
-	memory_present(0, 0, end_pfn);
+	memory_present(0, 0, max_pfn);
 	sparse_init();
 	free_area_init_nodes(max_zone_pfns);
 }

@@ -734,8 +729,8 @@ void __init mem_init(void)
 #else
 	totalram_pages = free_all_bootmem();
 #endif
-	reservedpages = end_pfn - totalram_pages -
-					absent_pages_in_range(0, end_pfn);
+	reservedpages = max_pfn - totalram_pages -
+					absent_pages_in_range(0, max_pfn);
 	after_bootmem = 1;
 
 	codesize =  (unsigned long) &_etext - (unsigned long) &_text;

@@ -754,7 +749,7 @@ void __init mem_init(void)
 	printk(KERN_INFO "Memory: %luk/%luk available (%ldk kernel code, "
 				"%ldk reserved, %ldk data, %ldk init)\n",
 		(unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
-		end_pfn << (PAGE_SHIFT-10),
+		max_pfn << (PAGE_SHIFT-10),
 		codesize >> 10,
 		reservedpages << (PAGE_SHIFT-10),
 		datasize >> 10,

@@ -854,7 +849,7 @@ int __init reserve_bootmem_generic(unsig
 #endif
 	unsigned long pfn = phys >> PAGE_SHIFT;
 
-	if (pfn >= end_pfn) {
+	if (pfn >= max_pfn) {
 		/*
 		 * This can happen with kdump kernels when accessing
 		 * firmware tables:

arch/x86/mm/k8topology_64.c +2 -2

Index: linux-2.6/arch/x86/mm/k8topology_64.c
===================================================================
@@ -143,8 +143,8 @@ int __init k8_scan_nodes(unsigned long s
 		limit |= (1<<24)-1;
 		limit++;
 
-		if (limit > end_pfn << PAGE_SHIFT)
-			limit = end_pfn << PAGE_SHIFT;
+		if (limit > max_pfn << PAGE_SHIFT)
+			limit = max_pfn << PAGE_SHIFT;
 		if (limit <= base)
 			continue;

arch/x86/mm/numa_64.c +2 -2

Index: linux-2.6/arch/x86/mm/numa_64.c
===================================================================
@@ -86,7 +86,7 @@ static int __init allocate_cachealigned_
 
 	addr = 0x8000;
 	nodemap_size = round_up(sizeof(s16) * memnodemapsize, L1_CACHE_BYTES);
-	nodemap_addr = find_e820_area(addr, end_pfn<<PAGE_SHIFT,
+	nodemap_addr = find_e820_area(addr, max_pfn<<PAGE_SHIFT,
 				      nodemap_size, L1_CACHE_BYTES);
 	if (nodemap_addr == -1UL) {
 		printk(KERN_ERR

@@ -581,7 +581,7 @@ void __init paging_init(void)
 	memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
 	max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
 	max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
-	max_zone_pfns[ZONE_NORMAL] = end_pfn;
+	max_zone_pfns[ZONE_NORMAL] = max_pfn;
 
 	sparse_memory_present_with_active_regions(MAX_NUMNODES);
 	sparse_init();

arch/x86/mm/srat_64.c +1 -1

Index: linux-2.6/arch/x86/mm/srat_64.c
===================================================================
@@ -299,7 +299,7 @@ static int __init nodes_cover_memory(con
 			pxmram = 0;
 	}
 
-	e820ram = end_pfn - absent_pages_in_range(0, end_pfn);
+	e820ram = max_pfn - absent_pages_in_range(0, max_pfn);
 	/* We seem to lose 3 pages somewhere. Allow a bit of slack. */
 	if ((long)(e820ram - pxmram) >= 1*1024*1024) {
 		printk(KERN_ERR

arch/x86/power/hibernate_64.c +1 -1

Index: linux-2.6/arch/x86/power/hibernate_64.c
===================================================================
@@ -83,7 +83,7 @@ static int set_up_temporary_mappings(voi
 
 	/* Set up the direct mapping from scratch */
 	start = (unsigned long)pfn_to_kaddr(0);
-	end = (unsigned long)pfn_to_kaddr(end_pfn);
+	end = (unsigned long)pfn_to_kaddr(max_pfn);
 
 	for (; start < end; start = next) {
 		pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);

include/asm-x86/page_64.h +3 -2

Index: linux-2.6/include/asm-x86/page_64.h
===================================================================
@@ -58,7 +58,8 @@
 void clear_page(void *page);
 void copy_page(void *to, void *from);
 
-extern unsigned long end_pfn;
+/* duplicated to the one in bootmem.h */
+extern unsigned long max_pfn;
 extern unsigned long phys_base;
 
 extern unsigned long __phys_addr(unsigned long);

@@ -87,7 +88,7 @@ extern void initmem_init(unsigned long s
 #endif	/* !__ASSEMBLY__ */
 
 #ifdef CONFIG_FLATMEM
-#define pfn_valid(pfn)          ((pfn) < end_pfn)
+#define pfn_valid(pfn)          ((pfn) < max_pfn)
 #endif

Yinghai Lu

author

2008-06-25 08:13 UTC #2 lore raw

PATCH 1/1 x86: Merge setup_32/64.c into setup.c

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/kernel/Makefile   |    2 
 arch/x86/kernel/setup.c    |  676 ++++++++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/setup_32.c |  543 ------------------------------------
 arch/x86/kernel/setup_64.c |  381 -------------------------
 include/asm-x86/setup.h    |    2 
 5 files changed, 670 insertions(+), 934 deletions(-)

arch/x86/kernel/Makefile +1 -1

Index: linux-2.6/arch/x86/kernel/Makefile
===================================================================
@@ -26,7 +26,7 @@ CFLAGS_paravirt.o	:= $(nostackp)
 obj-y			:= process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
 obj-y			+= traps_$(BITS).o irq_$(BITS).o
 obj-y			+= time_$(BITS).o ioport.o ldt.o
-obj-y			+= setup_$(BITS).o i8259.o irqinit_$(BITS).o setup.o
+obj-y			+= i8259.o irqinit_$(BITS).o setup.o
 obj-$(CONFIG_X86_32)	+= probe_roms_32.o
 obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o

arch/x86/kernel/setup.c +669 -7

698 lines not on this page · raw message

include/asm-x86/setup.h +0 -2

Index: linux-2.6/include/asm-x86/setup.h
===================================================================
@@ -38,8 +38,6 @@ void reserve_crashkernel(void);
 #ifndef __ASSEMBLY__
 #include <asm/bootparam.h>
 
-void reserve_standard_io_resources(void);
-
 #ifndef _SETUP
 
 /*

arch/x86/kernel/setup_64.c deleted +0 ~~-381~~

381 lines not on this page · raw message

arch/x86/kernel/setup_32.c deleted +0 ~~-543~~

543 lines not on this page · raw message

could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?

it would still result in exactly the same end result - but is much more bisectable (and reviewable, etc.). A bit like how arch/x86/mm/ioremap.c or arch/x86/mm/pageattr.c was unified.

maybe it can be done in less than 10 patches - but it guess it should be rather something in the neighborhood of 20 patches. Changes like this:

- /*

-        * NOTE: before this point _nobody_ is allowed to allocate
-        * any memory using the bootmem allocator.  Although the
-        * allocator is now initialised only the first 8Mb of the kernel
-        * virtual address space has been mapped.  All allocations before
-        * paging_init() has completed must use the alloc_bootmem_low_pages()
-        * variant (which allocates DMA'able memory) and care must be taken
-        * not to exceed the 8Mb limit.
-        */

should be in a separate patch - you removed this restriction from the x86 architecture via your earlier patches, so the removal of the comment comes from that (and deserves a separate commit), not purely from the mechanic unification in the end.

other changes like this:

-#ifdef CONFIG_X86_FIND_SMP_CONFIG
+#if defined(CONFIG_X86_FIND_SMP_CONFIG) && defined(CONFIG_X86_32) || \
+ defined(CONFIG_X86_MPPARSE) && defined(CONFIG_X86_64)

here you fix coding style:

- /*
- * Parse SRAT to discover nodes.
- */
- acpi_numa_init();
+ /*
+ * Parse SRAT to discover nodes.
+ */
+ acpi_numa_init();

etc. etc. You do a lot more very useful work than the plain single unification patch you sent tells us - all these changes should be split up.

[ and in the unlikely event of there being a bug somewhere in this 1600
lines patch, a splitup is also useful for finding bugs :-) ]

Ingo

Yinghai Lu

author

2008-06-25 15:45 UTC #4 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 14 lines · Ingo Molnar

Quoted 10 lines · Yinghai Lu

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/kernel/Makefile   |    2
 arch/x86/kernel/setup.c    |  676 ++++++++++++++++++++++++++++++++++++++++++++-
 arch/x86/kernel/setup_32.c |  543 ------------------------------------
 arch/x86/kernel/setup_64.c |  381 -------------------------
 include/asm-x86/setup.h    |    2
 5 files changed, 670 insertions(+), 934 deletions(-)

Quoted 6 lines

very nice!
could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?

OK, someone (Mike Triavis) already stole setup.c for X86_NUMA.

You need to change that setup.c to other name. or split it away...

Quoted 18 lines

it would still result in exactly the same end result - but is much more bisectable (and reviewable, etc.). A bit like how arch/x86/mm/ioremap.c or arch/x86/mm/pageattr.c was unified.
maybe it can be done in less than 10 patches - but it guess it should be rather something in the neighborhood of 20 patches. Changes like this:
arch/x86/kernel/setup_32.c deleted +0 -9
-       /*
-        * NOTE: before this point _nobody_ is allowed to allocate
-        * any memory using the bootmem allocator.  Although the
-        * allocator is now initialised only the first 8Mb of the kernel
-        * virtual address space has been mapped.  All allocations before
-        * paging_init() has completed must use the alloc_bootmem_low_pages()
-        * variant (which allocates DMA'able memory) and care must be taken
-        * not to exceed the 8Mb limit.
-        */

Quoted 4 lines

should be in a separate patch - you removed this restriction from the x86 architecture via your earlier patches, so the removal of the comment comes from that (and deserves a separate commit), not purely from the mechanic unification in the end.

OK.

Quoted 10 lines

other changes like this:
arch/x86/kernel/setup.c +2 -1
-#ifdef CONFIG_X86_FIND_SMP_CONFIG
+#if defined(CONFIG_X86_FIND_SMP_CONFIG) && defined(CONFIG_X86_32) || \
+    defined(CONFIG_X86_MPPARSE) && defined(CONFIG_X86_64)
here you fix coding style:

arch/x86/kernel/setup.c static int __init setup_elfcorehdr(char · line 1079

Quoted 8 lines

arch/x86/kernel/setup.c +4 -4

-        /*
-         * Parse SRAT to discover nodes.
-         */
-        acpi_numa_init();
+       /*
+        * Parse SRAT to discover nodes.
+        */
+       acpi_numa_init();

Quoted 3 lines

etc. etc. You do a lot more very useful work than the plain single unification patch you sent tells us - all these changes should be split up.

Ingo Molnar

2008-06-25 16:43 UTC #5 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 5 lines · Yinghai Lu

Quoted 5 lines

Quoted 2 lines

 include/asm-x86/setup.h    |    2
 5 files changed, 670 insertions(+), 934 deletions(-)

very nice!

Quoted 8 lines

Quoted 4 lines
could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?
OK, someone (Mike Triavis) already stole setup.c for X86_NUMA.
You need to change that setup.c to other name. or split it away...

hm, that change was supposed to be the seed of a unification. So if it actually hinders you, feel free to move it to a different file. Obviously it is setup_32.c and setup_64.c that should be unified into setup.c.

Ingo

Yinghai Lu

author

2008-06-25 17:28 UTC #6 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 13 lines · Ingo Molnar

Quoted 10 lines · Yinghai Lu
Quoted 9 lines
Quoted 2 lines
 include/asm-x86/setup.h    |    2
 5 files changed, 670 insertions(+), 934 deletions(-)
very nice!
could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?

Quoted 8 lines

Quoted 3 lines
OK, someone (Mike Triavis) already stole setup.c for X86_NUMA.
You need to change that setup.c to other name. or split it away...
hm, that change was supposed to be the seed of a unification. So if it actually hinders you, feel free to move it to a different file. Obviously it is setup_32.c and setup_64.c that should be unified into setup.c.

ok, I will change that setup_percpu.c

Mike Travis

2008-06-25 17:39 UTC #7 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 14 lines · Yinghai Lu

Quoted 13 lines · Ingo Molnar
Quoted 11 lines · Yinghai Lu
Quoted 8 lines
Quoted 2 lines
 include/asm-x86/setup.h    |    2
 5 files changed, 670 insertions(+), 934 deletions(-)
very nice!
could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?
OK, someone (Mike Triavis) already stole setup.c for X86_NUMA.
You need to change that setup.c to other name. or split it away...

Quoted 8 lines

Quoted 4 lines
hm, that change was supposed to be the seed of a unification. So if it actually hinders you, feel free to move it to a different file. Obviously it is setup_32.c and setup_64.c that should be unified into setup.c.
ok, I will change that setup_percpu.c
YH

One thing I was trying to do was to merge more stuff from setup_32/64 into setup.c. Unfortunately, there was some test failures on i386 that I did not have time to debug. But the file existed before my time. ;-)

Why does the current setup.c need to be renamed and not simply add the merged changes into it?

Thanks,
Mike

Yinghai Lu

author

2008-06-25 17:46 UTC #8 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 22 lines · Mike Travis

Quoted 21 lines · Yinghai Lu
Quoted 10 lines · Ingo Molnar
Quoted 8 lines · Yinghai Lu
Quoted 8 lines
Quoted 2 lines
 include/asm-x86/setup.h    |    2
 5 files changed, 670 insertions(+), 934 deletions(-)
very nice!
could we please split this up into several, gradual steps that bring setup_32.c and setup_64.c to exactly the same content - where the final patch just renames arch/x86/kernel/setup_32.c to arch/x86/kernel/setup.c and deletes arch/x86/kernel/setup_64.c ?
Quoted 7 lines
Quoted 3 lines
OK, someone (Mike Triavis) already stole setup.c for X86_NUMA.
You need to change that setup.c to other name. or split it away...
hm, that change was supposed to be the seed of a unification. So if it actually hinders you, feel free to move it to a different file. Obviously it is setup_32.c and setup_64.c that should be unified into setup.c.
ok, I will change that setup_percpu.c

Quoted 8 lines

Quoted 1 line
YH
One thing I was trying to do was to merge more stuff from setup_32/64 into setup.c. Unfortunately, there was some test failures on i386 that I did not have time to debug. But the file existed before my time. ;-)
Why does the current setup.c need to be renamed and not simply add the merged changes into it?

Ingo want make setup_32.c have everything (in 10 patches), and then rename setup_32.c to setup.c and delete setup_64.c

will move numa related to setup_numa.c or numa.c

H. Peter Anvin

reviewer

2008-06-25 17:49 UTC #9 lore raw

Re: [PATCH] x86: Merge setup_32/64.c into setup.c

Quoted 6 lines · Yinghai Lu

Ingo want make setup_32.c have everything (in 10 patches), and then rename setup_32.c to setup.c and delete setup_64.c
will move numa related to setup_numa.c or numa.c

FWIW, I personally would like to see initialization-only code moved out of arch/x86/kernel at some point. Right now "kernel" is a catch-all, in particular, it mixes drivers, runtime core code, and initialization code.

-hpa

Ingo Molnar

Applied

2008-06-25 15:42 UTC #10 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

In reply to Yinghai Lu

Quoted 3 lines · Yinghai Lu

and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>

applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:

Ingo Molnar (1):
Merge branch 'x86/setup-memory'

Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit

Ingo

Jeremy Fitzhardinge

2008-06-25 21:31 UTC #11 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

Quoted 13 lines · Ingo Molnar

Quoted 4 lines · Yinghai Lu
and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>
applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:
Ingo Molnar (1):
Merge branch 'x86/setup-memory'

Quoted 8 lines

Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit

Did you CC: this to me to indicate that "x86_64: replace end_pfn with num_physpages" conflicts massively with this patch? Fortunately I don't depend on it, so I don't mind much.

How does "max_pfn" differ from "num_physpages"? Should one of them go as well?

Yinghai Lu

author

2008-06-25 21:57 UTC #12 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

Quoted 26 lines · Jeremy Fitzhardinge

Quoted 16 lines · Ingo Molnar
Quoted 5 lines · Yinghai Lu
and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>
applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:
Ingo Molnar (1):
Merge branch 'x86/setup-memory'
Quoted 8 lines
Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit

Quoted 6 lines

Did you CC: this to me to indicate that "x86_64: replace end_pfn with num_physpages" conflicts massively with this patch? Fortunately I don't depend on it, so I don't mind much.
How does "max_pfn" differ from "num_physpages"? Should one of them go as well?

64bit setup_arch assign num_physpages with end_pfn...

and max_pfn is defined in linux/bootmem.h
num_physpages is defined in linux/mm.h

Jeremy Fitzhardinge

2008-06-25 22:21 UTC #13 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

Quoted 32 lines · Yinghai Lu

Quoted 30 lines · Jeremy Fitzhardinge
Quoted 15 lines · Ingo Molnar
Quoted 5 lines · Yinghai Lu
and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>
applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:
Ingo Molnar (1):
Merge branch 'x86/setup-memory'
Quoted 9 lines
Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit
Did you CC: this to me to indicate that "x86_64: replace end_pfn with num_physpages" conflicts massively with this patch? Fortunately I don't depend on it, so I don't mind much.

Quoted 6 lines

Quoted 3 lines
How does "max_pfn" differ from "num_physpages"? Should one of them go as well?
64bit setup_arch assign num_physpages with end_pfn...

I posted a patch to remove end_pfn and replace it with num_physpages everywhere, which obviously clashed badly with your patch ;)

Quoted 2 lines

and max_pfn is defined in linux/bootmem.h
num_physpages is defined in linux/mm.h

Do they contain separate values? Do they mean different things?

Yinghai Lu

author

2008-06-25 23:15 UTC #14 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

Quoted 44 lines · Jeremy Fitzhardinge

Quoted 43 lines · Yinghai Lu
Quoted 38 lines · Jeremy Fitzhardinge
Quoted 18 lines · Ingo Molnar
Quoted 6 lines · Yinghai Lu
and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>
applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:
Ingo Molnar (1):
Merge branch 'x86/setup-memory'
Quoted 9 lines
Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit
Did you CC: this to me to indicate that "x86_64: replace end_pfn with num_physpages" conflicts massively with this patch? Fortunately I don't depend on it, so I don't mind much.
How does "max_pfn" differ from "num_physpages"? Should one of them go as well?

Quoted 5 lines

Quoted 2 lines
64bit setup_arch assign num_physpages with end_pfn...
I posted a patch to remove end_pfn and replace it with num_physpages everywhere, which obviously clashed badly with your patch ;)

32bit has max_pfn, max_low_pfn, max_pfn_mapped...and min_low_pfn.

Quoted 5 lines

Quoted 3 lines
and max_pfn is defined in linux/bootmem.h
num_physpages is defined in linux/mm.h
Do they contain separate values? Do they mean different things?

x86 64 bit that they are same. num_phypages = max_pfn 32 bit when HIGHMEM=y, it is same.num_phypages = max_pfn
when HIGHMEM=n, num_phypages = max_low_pfn

Jeremy Fitzhardinge

2008-06-25 23:16 UTC #15 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

Quoted 4 lines · Yinghai Lu

x86 64 bit that they are same. num_phypages = max_pfn 32 bit when HIGHMEM=y, it is same.num_phypages = max_pfn
when HIGHMEM=n, num_phypages = max_low_pfn

OK, that makes sense.

Thanks,
J

Ingo Molnar

2008-06-26 10:05 UTC #16 lore raw

Re: [PATCH] x86: remove end_pfn in 64bit

In reply to Jeremy Fitzhardinge

Quoted 24 lines · Jeremy Fitzhardinge

Quoted 14 lines · Ingo Molnar
Quoted 4 lines · Yinghai Lu
and use max_pfn directly.
Signed-off-by Yinghai Lu <[email protected]>
applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these patches:
Ingo Molnar (1):
Merge branch 'x86/setup-memory'
Quoted 8 lines
Yinghai Lu (6):
x86: fix e820_update_range size when overlapping
x86: get max_pfn_mapped in init_memory_mapping
x86: add table_top check for alloc_low_page in 64 bit
x86: change size if e820_update/remove_range
x86: numa 32 using apicid_2_node to get node for logical_apicid
x86: remove end_pfn in 64bit

Quoted 3 lines

Did you CC: this to me to indicate that "x86_64: replace end_pfn with num_physpages" conflicts massively with this patch? Fortunately I don't depend on it, so I don't mind much.

yeah, wanted to notify you, in case you were wondering about interaction in this area :)

Ingo