Message ID | 1360894992-14818-2-git-send-email-lig.fnst@cn.fujitsu.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Fri, 15 Feb 2013, liguang wrote: > srat table should present only on acpi domain, > seems mm/ is not the right place for it. > > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> This doesn't apply to Linus' tree nor does it apply to linux-next. Which tree are you basing this on? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-19?? 13:21 -0800?David Rientjes??? > On Fri, 15 Feb 2013, liguang wrote: > > > srat table should present only on acpi domain, > > seems mm/ is not the right place for it. > > > > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> > > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which > tree are you basing this on? I did based on linux-next, but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760 which you may want to see. let me see why it missed. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-20?? 09:39 +0800?li guang??? > ? 2013-02-19?? 13:21 -0800?David Rientjes??? > > On Fri, 15 Feb 2013, liguang wrote: > > > > > srat table should present only on acpi domain, > > > seems mm/ is not the right place for it. > > > > > > Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> > > > Signed-off-by: liguang <lig.fnst@cn.fujitsu.com> > > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which > > tree are you basing this on? > > I did based on linux-next, > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760 > which you may want to see. > let me see why it missed. I pulled latest for linux-next and can apply my patches smoothly. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 20 Feb 2013, li guang wrote: > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which > > > tree are you basing this on? > > > > I did based on linux-next, > > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760 > > which you may want to see. > > let me see why it missed. > > I pulled latest for linux-next > and can apply my patches smoothly. > No, it doesn't. From next-20130219, you're missing at least two patches: 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node") 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT") I'm trying to be patient in reviewing your patches, but please double check your work. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-19?? 18:08 -0800?David Rientjes??? > On Wed, 20 Feb 2013, li guang wrote: > > > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which > > > > tree are you basing this on? > > > > > > I did based on linux-next, > > > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760 > > > which you may want to see. > > > let me see why it missed. > > > > I pulled latest for linux-next > > and can apply my patches smoothly. > > > > No, it doesn't. From next-20130219, you're missing at least two patches: > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node") > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT") > > I'm trying to be patient in reviewing your patches, but please double > check your work. I have to say my latest pull has these commit, and can apply successfully. really don't know why you can't apply. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-20?? 10:21 +0800?li guang??? > ? 2013-02-19?? 18:08 -0800?David Rientjes??? > > On Wed, 20 Feb 2013, li guang wrote: > > > > > > > This doesn't apply to Linus' tree nor does it apply to linux-next. Which > > > > > tree are you basing this on? > > > > > > > > I did based on linux-next, > > > > but it seems without commit 479a99a8e510c8839e0d3d3de8391f8bc61b9760 > > > > which you may want to see. > > > > let me see why it missed. > > > > > > I pulled latest for linux-next > > > and can apply my patches smoothly. > > > > > > > No, it doesn't. From next-20130219, you're missing at least two patches: > > > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node") > > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT") > > > > I'm trying to be patient in reviewing your patches, but please double > > check your work. > > I have to say my latest pull has these commit, and can apply > successfully. > really don't know why you can't apply. > I mean although my patches did not based on latest linux-next(miss several commits), but as I can see, they can be applied to latest linux-next (tag next-20130218) successfully. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 20 Feb 2013, li guang wrote: > > > No, it doesn't. From next-20130219, you're missing at least two patches: > > > > > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node") > > > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT") > > > > > > I'm trying to be patient in reviewing your patches, but please double > > > check your work. > > > > I have to say my latest pull has these commit, and can apply > > successfully. > > really don't know why you can't apply. You should not be pulling linux-next, you should be fetching. > > I mean although my patches did not based on latest linux-next(miss > several commits), but as I can see, they can be applied to latest > linux-next (tag next-20130218) successfully. > next-20130218 is not the latest linux-next as I've already said. Do this: go to http://git.kernel.org/?p=linux/kernel/git/next/linux-next-history.git;a=blob_plain;f=arch/x86/mm/srat.c;hb=HEAD and search for handle_movablemem(). That's one of the functions added in one of the commits I mentioned and was from February. Now search your patch for handle_movablemem(). See a problem? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-19?? 19:04 -0800?David Rientjes??? > On Wed, 20 Feb 2013, li guang wrote: > > > > > No, it doesn't. From next-20130219, you're missing at least two patches: > > > > > > > > 3795e4893203 ("acpi, memory-hotplug: extend movablemem_map ranges to the end of node") > > > > 9a561f4dfd70 ("acpi, memory-hotplug: support getting hotplug info from SRAT") > > > > > > > > I'm trying to be patient in reviewing your patches, but please double > > > > check your work. > > > > > > I have to say my latest pull has these commit, and can apply > > > successfully. > > > really don't know why you can't apply. > > You should not be pulling linux-next, you should be fetching. > > > > I mean although my patches did not based on latest linux-next(miss > > several commits), but as I can see, they can be applied to latest > > linux-next (tag next-20130218) successfully. > > > > next-20130218 is not the latest linux-next as I've already said. Do this: > go to > http://git.kernel.org/?p=linux/kernel/git/next/linux-next-history.git;a=blob_plain;f=arch/x86/mm/srat.c;hb=HEAD > and search for handle_movablemem(). That's one of the functions added in > one of the commits I mentioned and was from February. Now search your > patch for handle_movablemem(). See a problem? Yes, I know there's no new changes in my patch as I said before(not based on lasted), but as I try to apply my patch(1/4), it will do the right work to move current srat.c from arch/x86/mm/ to arch/x86/kernel/acpi/ regardless of what I based is not latest. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 20 Feb 2013, li guang wrote: > Yes, I know there's no new changes in my patch as I said before(not > based on lasted), but as I try to apply my patch(1/4), it will do > the right work to move current srat.c from arch/x86/mm/ to > arch/x86/kernel/acpi/ regardless of what I based is not latest. > Sorry, but that makes no sense. Your patch cannot be used cleanly if there have been subsequent changes to a hunk prior to applying it -- in this case the hunk would be the entire file since you're removing it. These patches would also be pushed by the x86 maintainers, who are not cc'd on this patch, and I think it would be unfair to ask them to make up for your inability to generate a bleeding edge patch with linux-next. The changes already cited in this thread have been in linux-next for almost two weeks, yet you refuse to rebase on top of them. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
? 2013-02-19?? 23:00 -0800?David Rientjes??? > On Wed, 20 Feb 2013, li guang wrote: > > > Yes, I know there's no new changes in my patch as I said before(not > > based on lasted), but as I try to apply my patch(1/4), it will do > > the right work to move current srat.c from arch/x86/mm/ to > > arch/x86/kernel/acpi/ regardless of what I based is not latest. > > > > Sorry, but that makes no sense. Your patch cannot be used cleanly if > there have been subsequent changes to a hunk prior to applying it -- in > this case the hunk would be the entire file since you're removing it. > > These patches would also be pushed by the x86 maintainers, who are not > cc'd on this patch, and I think it would be unfair to ask them to make up > for your inability to generate a bleeding edge patch with linux-next. The > changes already cited in this thread have been in linux-next for almost > two weeks, yet you refuse to rebase on top of them. OK, I'd like to rebase, Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile index 163b225..98cea92 100644 --- a/arch/x86/kernel/acpi/Makefile +++ b/arch/x86/kernel/acpi/Makefile @@ -1,5 +1,6 @@ obj-$(CONFIG_ACPI) += boot.o obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup_$(BITS).o +obj-$(CONFIG_ACPI_NUMA) += srat.o ifneq ($(CONFIG_ACPI_PROCESSOR),) obj-y += cstate.o diff --git a/arch/x86/kernel/acpi/srat.c b/arch/x86/kernel/acpi/srat.c new file mode 100644 index 0000000..cdd0da9 --- /dev/null +++ b/arch/x86/kernel/acpi/srat.c @@ -0,0 +1,198 @@ +/* + * ACPI 3.0 based NUMA setup + * Copyright 2004 Andi Kleen, SuSE Labs. + * + * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs. + * + * Called from acpi_numa_init while reading the SRAT and SLIT tables. + * Assumes all memory regions belonging to a single proximity domain + * are in one chunk. Holes between them will be included in the node. + */ + +#include <linux/kernel.h> +#include <linux/acpi.h> +#include <linux/mmzone.h> +#include <linux/bitmap.h> +#include <linux/module.h> +#include <linux/topology.h> +#include <linux/bootmem.h> +#include <linux/memblock.h> +#include <linux/mm.h> +#include <asm/proto.h> +#include <asm/numa.h> +#include <asm/e820.h> +#include <asm/apic.h> +#include <asm/uv/uv.h> + +int acpi_numa __initdata; + +static __init int setup_node(int pxm) +{ + return acpi_map_pxm_to_node(pxm); +} + +static __init void bad_srat(void) +{ + printk(KERN_ERR "SRAT: SRAT not used.\n"); + acpi_numa = -1; +} + +static __init inline int srat_disabled(void) +{ + return acpi_numa < 0; +} + +/* Callback for SLIT parsing */ +void __init acpi_numa_slit_init(struct acpi_table_slit *slit) +{ + int i, j; + + for (i = 0; i < slit->locality_count; i++) + for (j = 0; j < slit->locality_count; j++) + numa_set_distance(pxm_to_node(i), pxm_to_node(j), + slit->entry[slit->locality_count * i + j]); +} + +/* Callback for Proximity Domain -> x2APIC mapping */ +void __init +acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa) +{ + int pxm, node; + int apic_id; + + if (srat_disabled()) + return; + if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) { + bad_srat(); + return; + } + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0) + return; + pxm = pa->proximity_domain; + apic_id = pa->apic_id; + if (!apic->apic_id_valid(apic_id)) { + printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n", + pxm, apic_id); + return; + } + node = setup_node(pxm); + if (node < 0) { + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm); + bad_srat(); + return; + } + + if (apic_id >= MAX_LOCAL_APIC) { + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node); + return; + } + set_apicid_to_node(apic_id, node); + node_set(node, numa_nodes_parsed); + acpi_numa = 1; + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n", + pxm, apic_id, node); +} + +/* Callback for Proximity Domain -> LAPIC mapping */ +void __init +acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) +{ + int pxm, node; + int apic_id; + + if (srat_disabled()) + return; + if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) { + bad_srat(); + return; + } + if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0) + return; + pxm = pa->proximity_domain_lo; + if (acpi_srat_revision >= 2) + pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8; + node = setup_node(pxm); + if (node < 0) { + printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm); + bad_srat(); + return; + } + + if (get_uv_system_type() >= UV_X2APIC) + apic_id = (pa->apic_id << 8) | pa->local_sapic_eid; + else + apic_id = pa->apic_id; + + if (apic_id >= MAX_LOCAL_APIC) { + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node); + return; + } + + set_apicid_to_node(apic_id, node); + node_set(node, numa_nodes_parsed); + acpi_numa = 1; + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n", + pxm, apic_id, node); +} + +#ifdef CONFIG_MEMORY_HOTPLUG +static inline int save_add_info(void) {return 1;} +#else +static inline int save_add_info(void) {return 0;} +#endif + +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */ +int __init +acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma) +{ + u64 start, end; + int node, pxm; + + if (srat_disabled()) + goto out_err; + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) + goto out_err_bad_srat; + if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0) + goto out_err; + if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info()) + goto out_err; + + start = ma->base_address; + end = start + ma->length; + pxm = ma->proximity_domain; + if (acpi_srat_revision <= 1) + pxm &= 0xff; + + node = setup_node(pxm); + if (node < 0) { + printk(KERN_ERR "SRAT: Too many proximity domains.\n"); + goto out_err_bad_srat; + } + + if (numa_add_memblk(node, start, end) < 0) + goto out_err_bad_srat; + + node_set(node, numa_nodes_parsed); + + printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n", + node, pxm, + (unsigned long long) start, (unsigned long long) end - 1); + + return 0; +out_err_bad_srat: + bad_srat(); +out_err: + return -1; +} + +void __init acpi_numa_arch_fixup(void) {} + +int __init x86_acpi_numa_init(void) +{ + int ret; + + ret = acpi_numa_init(); + if (ret < 0) + return ret; + return srat_disabled() ? -EINVAL : 0; +} diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile index 23d8e5f..d6f3692 100644 --- a/arch/x86/mm/Makefile +++ b/arch/x86/mm/Makefile @@ -24,7 +24,6 @@ obj-$(CONFIG_MMIOTRACE_TEST) += testmmiotrace.o obj-$(CONFIG_NUMA) += numa.o numa_$(BITS).o obj-$(CONFIG_AMD_NUMA) += amdtopology.o -obj-$(CONFIG_ACPI_NUMA) += srat.o obj-$(CONFIG_NUMA_EMU) += numa_emulation.o obj-$(CONFIG_MEMTEST) += memtest.o diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c deleted file mode 100644 index cdd0da9..0000000 --- a/arch/x86/mm/srat.c +++ /dev/null @@ -1,198 +0,0 @@ -/* - * ACPI 3.0 based NUMA setup - * Copyright 2004 Andi Kleen, SuSE Labs. - * - * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs. - * - * Called from acpi_numa_init while reading the SRAT and SLIT tables. - * Assumes all memory regions belonging to a single proximity domain - * are in one chunk. Holes between them will be included in the node. - */ - -#include <linux/kernel.h> -#include <linux/acpi.h> -#include <linux/mmzone.h> -#include <linux/bitmap.h> -#include <linux/module.h> -#include <linux/topology.h> -#include <linux/bootmem.h> -#include <linux/memblock.h> -#include <linux/mm.h> -#include <asm/proto.h> -#include <asm/numa.h> -#include <asm/e820.h> -#include <asm/apic.h> -#include <asm/uv/uv.h> - -int acpi_numa __initdata; - -static __init int setup_node(int pxm) -{ - return acpi_map_pxm_to_node(pxm); -} - -static __init void bad_srat(void) -{ - printk(KERN_ERR "SRAT: SRAT not used.\n"); - acpi_numa = -1; -} - -static __init inline int srat_disabled(void) -{ - return acpi_numa < 0; -} - -/* Callback for SLIT parsing */ -void __init acpi_numa_slit_init(struct acpi_table_slit *slit) -{ - int i, j; - - for (i = 0; i < slit->locality_count; i++) - for (j = 0; j < slit->locality_count; j++) - numa_set_distance(pxm_to_node(i), pxm_to_node(j), - slit->entry[slit->locality_count * i + j]); -} - -/* Callback for Proximity Domain -> x2APIC mapping */ -void __init -acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa) -{ - int pxm, node; - int apic_id; - - if (srat_disabled()) - return; - if (pa->header.length < sizeof(struct acpi_srat_x2apic_cpu_affinity)) { - bad_srat(); - return; - } - if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0) - return; - pxm = pa->proximity_domain; - apic_id = pa->apic_id; - if (!apic->apic_id_valid(apic_id)) { - printk(KERN_INFO "SRAT: PXM %u -> X2APIC 0x%04x ignored\n", - pxm, apic_id); - return; - } - node = setup_node(pxm); - if (node < 0) { - printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm); - bad_srat(); - return; - } - - if (apic_id >= MAX_LOCAL_APIC) { - printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node); - return; - } - set_apicid_to_node(apic_id, node); - node_set(node, numa_nodes_parsed); - acpi_numa = 1; - printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n", - pxm, apic_id, node); -} - -/* Callback for Proximity Domain -> LAPIC mapping */ -void __init -acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) -{ - int pxm, node; - int apic_id; - - if (srat_disabled()) - return; - if (pa->header.length != sizeof(struct acpi_srat_cpu_affinity)) { - bad_srat(); - return; - } - if ((pa->flags & ACPI_SRAT_CPU_ENABLED) == 0) - return; - pxm = pa->proximity_domain_lo; - if (acpi_srat_revision >= 2) - pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8; - node = setup_node(pxm); - if (node < 0) { - printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm); - bad_srat(); - return; - } - - if (get_uv_system_type() >= UV_X2APIC) - apic_id = (pa->apic_id << 8) | pa->local_sapic_eid; - else - apic_id = pa->apic_id; - - if (apic_id >= MAX_LOCAL_APIC) { - printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node); - return; - } - - set_apicid_to_node(apic_id, node); - node_set(node, numa_nodes_parsed); - acpi_numa = 1; - printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n", - pxm, apic_id, node); -} - -#ifdef CONFIG_MEMORY_HOTPLUG -static inline int save_add_info(void) {return 1;} -#else -static inline int save_add_info(void) {return 0;} -#endif - -/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */ -int __init -acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma) -{ - u64 start, end; - int node, pxm; - - if (srat_disabled()) - goto out_err; - if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) - goto out_err_bad_srat; - if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0) - goto out_err; - if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info()) - goto out_err; - - start = ma->base_address; - end = start + ma->length; - pxm = ma->proximity_domain; - if (acpi_srat_revision <= 1) - pxm &= 0xff; - - node = setup_node(pxm); - if (node < 0) { - printk(KERN_ERR "SRAT: Too many proximity domains.\n"); - goto out_err_bad_srat; - } - - if (numa_add_memblk(node, start, end) < 0) - goto out_err_bad_srat; - - node_set(node, numa_nodes_parsed); - - printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n", - node, pxm, - (unsigned long long) start, (unsigned long long) end - 1); - - return 0; -out_err_bad_srat: - bad_srat(); -out_err: - return -1; -} - -void __init acpi_numa_arch_fixup(void) {} - -int __init x86_acpi_numa_init(void) -{ - int ret; - - ret = acpi_numa_init(); - if (ret < 0) - return ret; - return srat_disabled() ? -EINVAL : 0; -}