Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1382989 > unrolled thread
| Started by | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| First post | 2016-04-20 03:50 +0200 |
| Last post | 2016-04-27 03:50 +0200 |
| Articles | 9 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH v5 00/14] ACPI NUMA support for ARM64 David Daney <ddaney.cavm@gmail.com> - 2016-04-20 03:50 +0200
[PATCH v5 09/14] acpi, numa: remove unneeded acpi_numa=1 David Daney <ddaney.cavm@gmail.com> - 2016-04-20 03:50 +0200
[PATCH v5 14/14] arm64, acpi, numa: Default enable ACPI_NUMA with NUMA David Daney <ddaney.cavm@gmail.com> - 2016-04-20 04:00 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Will Deacon <will.deacon@arm.com> - 2016-04-25 13:20 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Hanjun Guo <hanjun.guo@linaro.org> - 2016-04-26 07:40 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Will Deacon <will.deacon@arm.com> - 2016-04-26 14:20 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Hanjun Guo <hanjun.guo@linaro.org> - 2016-04-26 15:10 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Will Deacon <will.deacon@arm.com> - 2016-04-26 15:40 +0200
Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Hanjun Guo <hanjun.guo@linaro.org> - 2016-04-27 03:50 +0200
| From | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| Date | 2016-04-20 03:50 +0200 |
| Subject | [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rpPrb-8e3-3@gated-at.bofh.it> |
From: David Daney <david.daney@cavium.com>
Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
set introduce the ACPI based configuration to provide NUMA
information.
ACPI 5.1 already introduced NUMA support for ARM64, which can get the
NUMA domain information from SRAT and SLIT table, so parse those two
tables to get mappings from cpu/mem to numa node configuration and
system locality.
v5 updates:
- Fixed ia64 build failure by gating some unused functions with #if
CONFIG_{X86,ARM64}.
- Fixed section mismatch errors for X86 case.
- Removed unneeded #include from some files.
- Tested to build cleanly on ARM64, X86_64, IA64
v4 updates:
- Updated from Hanjun Guo's v3 patches.
- Rebased on top of v16 of device-tree NUMA patches.
- Reordered some of the changes so that we don't introduce code and
then change it several times in the patch set. New code is
introduced in its final form. Code reused from x86 is first moved
with no change, and then a separate patch to make any needed
changes.
- code that is used only by ia64, moved to architecture specific
files.
v3 updates:
- Deep investigation about the ACPI_DEBUG_PRINT() and remvoe
that for acpi/numa.c (patch 2/12)
- Remove the duplicate NULL check for table print (patch 3/12)
- Introduce CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP to remove duplicate
dummy function for acpi_numa_arch_fixup()
- Solve the problem that the mapping from logical cpu to numa node
is wrong which spotted out by Lorenzo
- cleanups for x86 and move acpi_numa_slit_init() and some other
functions to common place, then reduce the duplicate of x86
and arm64 (patch 7-12/12).
- rebased on top of 4.4 and Ganapat's v9 patch set.
[1]: https://lkml.org/lkml/2016/4/8/571
David Daney (1):
acpi, numa, srat: Improve SRAT error detection and add messages.
Hanjun Guo (11):
acpi, numa: Use pr_fmt() instead of printk
acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
acpi, numa: remove duplicate NULL check
acpi, numa: move acpi_numa_slit_init() to drivers/acpi/numa.c
arm64, numa: rework numa_add_memblk()
x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
acpi, numa: move bad_srat() and srat_disabled() to
drivers/acpi/numa.c
acpi, numa: remove unneeded acpi_numa=1
acpi, numa: Move acpi_numa_memory_affinity_init() to
drivers/acpi/numa.c
arm64, acpi, numa: NUMA support based on SRAT and SLIT
acpi, numa: Enable ACPI based NUMA on ARM64
Robert Richter (2):
acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
arm64, acpi, numa: Default enable ACPI_NUMA with NUMA
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 2 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 149 ++++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 2 +
arch/arm64/mm/numa.c | 17 ++--
arch/ia64/include/asm/acpi.h | 3 +
arch/ia64/kernel/acpi.c | 2 +-
arch/ia64/kernel/setup.c | 1 +
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 116 +---------------------
drivers/acpi/Kconfig | 4 +-
drivers/acpi/numa.c | 224 ++++++++++++++++++++++++++++++++----------
drivers/of/of_numa.c | 4 +-
include/acpi/acpi_numa.h | 4 +
include/linux/acpi.h | 18 +++-
17 files changed, 375 insertions(+), 183 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
--
1.7.11.7
[toc] | [next] | [standalone]
| From | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| Date | 2016-04-20 03:50 +0200 |
| Subject | [PATCH v5 09/14] acpi, numa: remove unneeded acpi_numa=1 |
| Message-ID | <rpPrd-8e3-41@gated-at.bofh.it> |
| In reply to | #1382989 |
From: Hanjun Guo <hanjun.guo@linaro.org> acpi_numa is default to 0, it's set to -1 when disable acpi numa or when a bad SRAT is parsed, and it's only consumed in srat_disabled() (compare it with 0) to continue parse the SRAT or not, so we don't need to set acpi_numa to 1 when we get a valid SRAT entry. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Robert Richter <rrichter@cavium.com> Signed-off-by: David Daney <david.daney@cavium.com> --- arch/x86/mm/srat.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c index 4217071f..30460f5 100644 --- a/arch/x86/mm/srat.c +++ b/arch/x86/mm/srat.c @@ -59,7 +59,6 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa) } 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); } @@ -101,7 +100,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) 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); } -- 1.7.11.7
[toc] | [prev] | [next] | [standalone]
| From | David Daney <ddaney.cavm@gmail.com> |
|---|---|
| Date | 2016-04-20 04:00 +0200 |
| Subject | [PATCH v5 14/14] arm64, acpi, numa: Default enable ACPI_NUMA with NUMA |
| Message-ID | <rpPAT-8hw-9@gated-at.bofh.it> |
| In reply to | #1382989 |
From: Robert Richter <rrichter@cavium.com> Signed-off-by: Robert Richter <rrichter@cavium.com> Signed-off-by: David Daney <david.daney@cavium.com> --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 5ce9f66..bacf245 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -292,7 +292,7 @@ config ACPI_NUMA bool "NUMA support" depends on NUMA depends on (X86 || IA64 || ARM64) - default y if IA64_GENERIC || IA64_SGI_SN2 + default y if IA64_GENERIC || IA64_SGI_SN2 || ARM64 config ACPI_CUSTOM_DSDT_FILE string "Custom DSDT Table file to include" -- 1.7.11.7
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-04-25 13:20 +0200 |
| Message-ID | <rrMIx-4QJ-5@gated-at.bofh.it> |
| In reply to | #1382989 |
Hi David,
On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
> set introduce the ACPI based configuration to provide NUMA
> information.
>
> ACPI 5.1 already introduced NUMA support for ARM64, which can get the
> NUMA domain information from SRAT and SLIT table, so parse those two
> tables to get mappings from cpu/mem to numa node configuration and
> system locality.
Whilst I've queued the main NUMA series for arm64, I'd really like to
see more movement on the generic header file cleanups that you posted
separately:
http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com
Given that this ACPI series already requires some significant cross-arch
interaction (which is actually good!), perhaps extending the clean-up
patches to encompass some of the ACPI bits might make sense, and we can
get that queued as a pre-requisite.
Will
> v5 updates:
>
> - Fixed ia64 build failure by gating some unused functions with #if
> CONFIG_{X86,ARM64}.
>
> - Fixed section mismatch errors for X86 case.
>
> - Removed unneeded #include from some files.
>
> - Tested to build cleanly on ARM64, X86_64, IA64
>
> v4 updates:
>
> - Updated from Hanjun Guo's v3 patches.
>
> - Rebased on top of v16 of device-tree NUMA patches.
>
> - Reordered some of the changes so that we don't introduce code and
> then change it several times in the patch set. New code is
> introduced in its final form. Code reused from x86 is first moved
> with no change, and then a separate patch to make any needed
> changes.
>
> - code that is used only by ia64, moved to architecture specific
> files.
>
> v3 updates:
> - Deep investigation about the ACPI_DEBUG_PRINT() and remvoe
> that for acpi/numa.c (patch 2/12)
>
> - Remove the duplicate NULL check for table print (patch 3/12)
>
> - Introduce CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP to remove duplicate
> dummy function for acpi_numa_arch_fixup()
>
> - Solve the problem that the mapping from logical cpu to numa node
> is wrong which spotted out by Lorenzo
>
> - cleanups for x86 and move acpi_numa_slit_init() and some other
> functions to common place, then reduce the duplicate of x86
> and arm64 (patch 7-12/12).
>
> - rebased on top of 4.4 and Ganapat's v9 patch set.
>
> [1]: https://lkml.org/lkml/2016/4/8/571
>
> David Daney (1):
> acpi, numa, srat: Improve SRAT error detection and add messages.
>
> Hanjun Guo (11):
> acpi, numa: Use pr_fmt() instead of printk
> acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
> acpi, numa: remove duplicate NULL check
> acpi, numa: move acpi_numa_slit_init() to drivers/acpi/numa.c
> arm64, numa: rework numa_add_memblk()
> x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
> acpi, numa: move bad_srat() and srat_disabled() to
> drivers/acpi/numa.c
> acpi, numa: remove unneeded acpi_numa=1
> acpi, numa: Move acpi_numa_memory_affinity_init() to
> drivers/acpi/numa.c
> arm64, acpi, numa: NUMA support based on SRAT and SLIT
> acpi, numa: Enable ACPI based NUMA on ARM64
>
> Robert Richter (2):
> acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
> arm64, acpi, numa: Default enable ACPI_NUMA with NUMA
>
> arch/arm64/include/asm/acpi.h | 8 ++
> arch/arm64/include/asm/numa.h | 2 +
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/acpi_numa.c | 149 ++++++++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 2 +
> arch/arm64/mm/numa.c | 17 ++--
> arch/ia64/include/asm/acpi.h | 3 +
> arch/ia64/kernel/acpi.c | 2 +-
> arch/ia64/kernel/setup.c | 1 +
> arch/x86/include/asm/acpi.h | 1 -
> arch/x86/mm/numa.c | 2 +-
> arch/x86/mm/srat.c | 116 +---------------------
> drivers/acpi/Kconfig | 4 +-
> drivers/acpi/numa.c | 224 ++++++++++++++++++++++++++++++++----------
> drivers/of/of_numa.c | 4 +-
> include/acpi/acpi_numa.h | 4 +
> include/linux/acpi.h | 18 +++-
> 17 files changed, 375 insertions(+), 183 deletions(-)
> create mode 100644 arch/arm64/kernel/acpi_numa.c
>
> --
> 1.7.11.7
>
[toc] | [prev] | [next] | [standalone]
| From | Hanjun Guo <hanjun.guo@linaro.org> |
|---|---|
| Date | 2016-04-26 07:40 +0200 |
| Subject | Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rs3T4-270-3@gated-at.bofh.it> |
| In reply to | #1386260 |
Hi Will, David, On 2016/4/26 0:47, David Daney wrote: > On 04/25/2016 04:13 AM, Will Deacon wrote: >> Hi David, >> >> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: >>> From: David Daney <david.daney@cavium.com> >>> >>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch >>> set introduce the ACPI based configuration to provide NUMA >>> information. >>> >>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the >>> NUMA domain information from SRAT and SLIT table, so parse those two >>> tables to get mappings from cpu/mem to numa node configuration and >>> system locality. >> >> Whilst I've queued the main NUMA series for arm64, I'd really like to >> see more movement on the generic header file cleanups that you posted >> separately: >> >> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com >> > > FWIW: Those patches should still apply. I am carrying them in my > development trees, and have not changed them in any way. > >> >> Given that this ACPI series already requires some significant cross-arch >> interaction (which is actually good!), perhaps extending the clean-up >> patches to encompass some of the ACPI bits might make sense, and we can >> get that queued as a pre-requisite. > > The cleanup patches you mention above are really independent of the ACPI > things. I have applied them both before and after the ACPI patches, and > both seem to work. With a quick perusal of the ACPI patches nothing > jumps out at me as being a candidate for inclusion in the header file > cleanup series. I agree. My patch set is ACPI related enablement, cleanups and consolidations, it would be good to merge as a single patch set as it's self-contained. Thanks Hanjun
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-04-26 14:20 +0200 |
| Subject | Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rsa89-7In-1@gated-at.bofh.it> |
| In reply to | #1387139 |
On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: > On 2016/4/26 0:47, David Daney wrote: > >On 04/25/2016 04:13 AM, Will Deacon wrote: > >>On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: > >>>From: David Daney <david.daney@cavium.com> > >>> > >>>Based on v16 of device-tree NUMA patch set for arm64 [1],this patch > >>>set introduce the ACPI based configuration to provide NUMA > >>>information. > >>> > >>>ACPI 5.1 already introduced NUMA support for ARM64, which can get the > >>>NUMA domain information from SRAT and SLIT table, so parse those two > >>>tables to get mappings from cpu/mem to numa node configuration and > >>>system locality. > >> > >>Whilst I've queued the main NUMA series for arm64, I'd really like to > >>see more movement on the generic header file cleanups that you posted > >>separately: > >> > >>http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com > >> > > > >FWIW: Those patches should still apply. I am carrying them in my > >development trees, and have not changed them in any way. What's your plan for getting them merged? > >>Given that this ACPI series already requires some significant cross-arch > >>interaction (which is actually good!), perhaps extending the clean-up > >>patches to encompass some of the ACPI bits might make sense, and we can > >>get that queued as a pre-requisite. > > > >The cleanup patches you mention above are really independent of the ACPI > >things. I have applied them both before and after the ACPI patches, and > >both seem to work. With a quick perusal of the ACPI patches nothing > >jumps out at me as being a candidate for inclusion in the header file > >cleanup series. > > I agree. My patch set is ACPI related enablement, cleanups and > consolidations, it would be good to merge as a single patch set > as it's self-contained. Up to you. I just thought you might want to avoid having two sets of cross-arch changes and the associated merging headaches that go with that. Will
[toc] | [prev] | [next] | [standalone]
| From | Hanjun Guo <hanjun.guo@linaro.org> |
|---|---|
| Date | 2016-04-26 15:10 +0200 |
| Subject | Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rsaUz-8ny-37@gated-at.bofh.it> |
| In reply to | #1387417 |
On 2016/4/26 20:15, Will Deacon wrote: > On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: >> On 2016/4/26 0:47, David Daney wrote: >>> On 04/25/2016 04:13 AM, Will Deacon wrote: >>>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: >>>>> From: David Daney <david.daney@cavium.com> >>>>> >>>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch >>>>> set introduce the ACPI based configuration to provide NUMA >>>>> information. >>>>> >>>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the >>>>> NUMA domain information from SRAT and SLIT table, so parse those two >>>>> tables to get mappings from cpu/mem to numa node configuration and >>>>> system locality. >>>> >>>> Whilst I've queued the main NUMA series for arm64, I'd really like to >>>> see more movement on the generic header file cleanups that you posted >>>> separately: >>>> >>>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com >>>> >>> >>> FWIW: Those patches should still apply. I am carrying them in my >>> development trees, and have not changed them in any way. > > What's your plan for getting them merged? This patch set touches lots of ACPI related file in arch/x86, arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be merged via ACPI tree by Rafael with your ack to ARM64 code, does it make sense? > >>>> Given that this ACPI series already requires some significant cross-arch >>>> interaction (which is actually good!), perhaps extending the clean-up >>>> patches to encompass some of the ACPI bits might make sense, and we can >>>> get that queued as a pre-requisite. >>> >>> The cleanup patches you mention above are really independent of the ACPI >>> things. I have applied them both before and after the ACPI patches, and >>> both seem to work. With a quick perusal of the ACPI patches nothing >>> jumps out at me as being a candidate for inclusion in the header file >>> cleanup series. >> >> I agree. My patch set is ACPI related enablement, cleanups and >> consolidations, it would be good to merge as a single patch set >> as it's self-contained. > > Up to you. I just thought you might want to avoid having two sets of > cross-arch changes and the associated merging headaches that go with > that. Good point, as I suggested above, it can go with ACPI tree if it's ok to you and Rafael. The problem we have now is that dt based core NUMA support for ARM64 is queued in your tree, that would be the headache. Thanks Hanjun
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-04-26 15:40 +0200 |
| Subject | Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rsbnA-9L-21@gated-at.bofh.it> |
| In reply to | #1387460 |
On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote: > On 2016/4/26 20:15, Will Deacon wrote: > >On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: > >>On 2016/4/26 0:47, David Daney wrote: > >>>On 04/25/2016 04:13 AM, Will Deacon wrote: > >>>>On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: > >>>>>From: David Daney <david.daney@cavium.com> > >>>>> > >>>>>Based on v16 of device-tree NUMA patch set for arm64 [1],this patch > >>>>>set introduce the ACPI based configuration to provide NUMA > >>>>>information. > >>>>> > >>>>>ACPI 5.1 already introduced NUMA support for ARM64, which can get the > >>>>>NUMA domain information from SRAT and SLIT table, so parse those two > >>>>>tables to get mappings from cpu/mem to numa node configuration and > >>>>>system locality. > >>>> > >>>>Whilst I've queued the main NUMA series for arm64, I'd really like to > >>>>see more movement on the generic header file cleanups that you posted > >>>>separately: > >>>> > >>>>http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com > >>>> > >>> > >>>FWIW: Those patches should still apply. I am carrying them in my > >>>development trees, and have not changed them in any way. > > > >What's your plan for getting them merged? > > This patch set touches lots of ACPI related file in arch/x86, > arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be > merged via ACPI tree by Rafael with your ack to ARM64 code, does > it make sense? It doesn't touch anything in drivers/acpi/... are you following the link above? > >>>>Given that this ACPI series already requires some significant cross-arch > >>>>interaction (which is actually good!), perhaps extending the clean-up > >>>>patches to encompass some of the ACPI bits might make sense, and we can > >>>>get that queued as a pre-requisite. > >>> > >>>The cleanup patches you mention above are really independent of the ACPI > >>>things. I have applied them both before and after the ACPI patches, and > >>>both seem to work. With a quick perusal of the ACPI patches nothing > >>>jumps out at me as being a candidate for inclusion in the header file > >>>cleanup series. > >> > >>I agree. My patch set is ACPI related enablement, cleanups and > >>consolidations, it would be good to merge as a single patch set > >>as it's self-contained. > > > >Up to you. I just thought you might want to avoid having two sets of > >cross-arch changes and the associated merging headaches that go with > >that. > > Good point, as I suggested above, it can go with ACPI tree if it's ok > to you and Rafael. The problem we have now is that dt based core NUMA > support for ARM64 is queued in your tree, that would be the headache. Sorry, but if you wanted me *not* to queue the patches, then you should have said so (similarly, if you wanted a stable branch). I'm not rebasing our for-next/core branch now. Will
[toc] | [prev] | [next] | [standalone]
| From | Hanjun Guo <hanjun.guo@linaro.org> |
|---|---|
| Date | 2016-04-27 03:50 +0200 |
| Subject | Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 |
| Message-ID | <rsmM1-16B-1@gated-at.bofh.it> |
| In reply to | #1387481 |
Hi Will, On 2016/4/26 21:35, Will Deacon wrote: > On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote: >> On 2016/4/26 20:15, Will Deacon wrote: >>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote: >>>> On 2016/4/26 0:47, David Daney wrote: >>>>> On 04/25/2016 04:13 AM, Will Deacon wrote: >>>>>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: >>>>>>> From: David Daney <david.daney@cavium.com> >>>>>>> >>>>>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch >>>>>>> set introduce the ACPI based configuration to provide NUMA >>>>>>> information. >>>>>>> >>>>>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the >>>>>>> NUMA domain information from SRAT and SLIT table, so parse those two >>>>>>> tables to get mappings from cpu/mem to numa node configuration and >>>>>>> system locality. >>>>>> >>>>>> Whilst I've queued the main NUMA series for arm64, I'd really like to >>>>>> see more movement on the generic header file cleanups that you posted >>>>>> separately: >>>>>> >>>>>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com >>>>>> >>>>> >>>>> FWIW: Those patches should still apply. I am carrying them in my >>>>> development trees, and have not changed them in any way. >>> >>> What's your plan for getting them merged? >> >> This patch set touches lots of ACPI related file in arch/x86, >> arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be >> merged via ACPI tree by Rafael with your ack to ARM64 code, does >> it make sense? > > It doesn't touch anything in drivers/acpi/... are you following the link > above? Sorry, my bad, I though you were talking about this ACPI NUMA support for ARM64 patch set. > >>>>>> Given that this ACPI series already requires some significant cross-arch >>>>>> interaction (which is actually good!), perhaps extending the clean-up >>>>>> patches to encompass some of the ACPI bits might make sense, and we can >>>>>> get that queued as a pre-requisite. >>>>> >>>>> The cleanup patches you mention above are really independent of the ACPI >>>>> things. I have applied them both before and after the ACPI patches, and >>>>> both seem to work. With a quick perusal of the ACPI patches nothing >>>>> jumps out at me as being a candidate for inclusion in the header file >>>>> cleanup series. >>>> >>>> I agree. My patch set is ACPI related enablement, cleanups and >>>> consolidations, it would be good to merge as a single patch set >>>> as it's self-contained. >>> >>> Up to you. I just thought you might want to avoid having two sets of >>> cross-arch changes and the associated merging headaches that go with >>> that. >> >> Good point, as I suggested above, it can go with ACPI tree if it's ok >> to you and Rafael. The problem we have now is that dt based core NUMA >> support for ARM64 is queued in your tree, that would be the headache. > > Sorry, but if you wanted me *not* to queue the patches, then you should > have said so (similarly, if you wanted a stable branch). I'm not rebasing > our for-next/core branch now. I misread the message above, I'm really sorry if I did something offending you, I didn't mean that. How about this patch set? We only get few comments on it, your comments on it are appreciated. Thanks Hanjun
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web