Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1398617 > unrolled thread

Re: [PATCH v6 00/14] ACPI NUMA support for ARM64

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-11 02:50 +0200
    Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 Will Deacon <will.deacon@arm.com> - 2016-05-11 12:50 +0200
      Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-11 22:40 +0200
        Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-11 23:30 +0200
          Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-12 00:30 +0200
            Re: [PATCH v6 00/14] ACPI NUMA support for ARM64 Will Deacon <will.deacon@arm.com> - 2016-05-12 11:00 +0200

#1398617 — Re: [PATCH v6 00/14] ACPI NUMA support for ARM64

On Wed, Apr 27, 2016 at 8:07 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> From: David Daney <david.daney@cavium.com>
>
> Based on git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> for-next/core branch at commit 643d703d2d2d ("arm64: compat: Check for
> AArch32 state")
>
> 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.
>
> v6 updates:
>
>  - Changed message printed in 13/14 to omit meaningless "cpu"
>    number. (noted by Dennis Chen and Hanjun Guo)
>
>  - New patch 7/14 to print different messages for NUMA disabled case.
>    (noted by Dennis Chen)
>
>  - Squashed two patches into 14/14.
>
>  - Added Reviewed-by to 4/14
>
> 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.
>
>
> David Daney (2):
>   arm64, numa: Cleanup NUMA disabled messages.
>   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 (1):
>   acpi, numa: Move acpi_numa_arch_fixup() to ia64 only

I need ACKs from the ARM64 maintainers on patches [6-7/13] and [13-14/14].

The rest looks good to me, so I can apply the series once the above
have been ACKed.

Thanks,
Rafael

[toc] | [next] | [standalone]

#1398932

On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote:
> On Wed, Apr 27, 2016 at 8:07 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> > From: David Daney <david.daney@cavium.com>
> >
> > Based on git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > for-next/core branch at commit 643d703d2d2d ("arm64: compat: Check for
> > AArch32 state")

[...]

> > David Daney (2):
> >   arm64, numa: Cleanup NUMA disabled messages.
> >   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 (1):
> >   acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
> 
> I need ACKs from the ARM64 maintainers on patches [6-7/13] and [13-14/14].

There's also a dependency on the arm64 for-next/core branch, so I've been
largely ignoring this as far as 4.6 is concerned and was planning to take
a proper look for 4.7 once the upcoming merge window is out of the way.

Will

[toc] | [prev] | [next] | [standalone]

#1399498

On Wed, May 11, 2016 at 12:40 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote:
>> On Wed, Apr 27, 2016 at 8:07 PM, David Daney <ddaney.cavm@gmail.com> wrote:
>> > From: David Daney <david.daney@cavium.com>
>> >
>> > Based on git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>> > for-next/core branch at commit 643d703d2d2d ("arm64: compat: Check for
>> > AArch32 state")
>
> [...]
>
>> > David Daney (2):
>> >   arm64, numa: Cleanup NUMA disabled messages.
>> >   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 (1):
>> >   acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
>>
>> I need ACKs from the ARM64 maintainers on patches [6-7/13] and [13-14/14].
>
> There's also a dependency on the arm64 for-next/core branch, so I've been
> largely ignoring this as far as 4.6 is concerned and was planning to take
> a proper look for 4.7 once the upcoming merge window is out of the way.

That would be 4.7 and 4.8 respectively I suppose?

Anyway, Catalin has ACKed all of them except for the [13/14], so
technically I can apply [1-12/14] now and then [13-14/14] can be
applied when they are ready.

Do you think there will be any problems with merging [6-7/14] into 4.7
via the ACPI tree?

[toc] | [prev] | [next] | [standalone]

#1399522

On Wed, May 11, 2016 at 11:08 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 05/11/2016 01:35 PM, Rafael J. Wysocki wrote:
>>
>> On Wed, May 11, 2016 at 12:40 PM, Will Deacon <will.deacon@arm.com> wrote:
>>>
>>> On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote:
>>>>
>>>> On Wed, Apr 27, 2016 at 8:07 PM, David Daney <ddaney.cavm@gmail.com>
>>>> wrote:
>>>>>
>>>>> From: David Daney <david.daney@cavium.com>
>>>>>
>>>>> Based on git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>>>>> for-next/core branch at commit 643d703d2d2d ("arm64: compat: Check for
>>>>> AArch32 state")
>>>
>>>
>>> [...]
>>>
>>>>> David Daney (2):
>>>>>    arm64, numa: Cleanup NUMA disabled messages.
>>>>>    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 (1):
>>>>>    acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
>>>>
>>>>
>>>> I need ACKs from the ARM64 maintainers on patches [6-7/13] and
>>>> [13-14/14].
>>>
>>>
>>> There's also a dependency on the arm64 for-next/core branch, so I've been
>>> largely ignoring this as far as 4.6 is concerned and was planning to take
>>> a proper look for 4.7 once the upcoming merge window is out of the way.
>>
>>
>> That would be 4.7 and 4.8 respectively I suppose?
>>
>> Anyway, Catalin has ACKed all of them except for the [13/14], so
>> technically I can apply [1-12/14] now and then [13-14/14] can be
>> applied when they are ready.
>>
>> Do you think there will be any problems with merging [6-7/14] into 4.7
>> via the ACPI tree?
>>
>
> I would defer to the arm64 maintainers for decisions about the arm64
> specific parts of the patch set.  That said, many of the arm64 specific
> patches depend on the arm64 for-next/core branch, so you would have to be
> careful about merge ordering if you pull these in before the for-next/core
> branch is merged.

Fair enough.  I will wait for an update then.

> Also FWIW, I plan on addressing Catalin's comments about 13/14 and posting a
> new version of the patch set in the next day or two.

OK, but in that case it won't be considered for 4.7 (at least not by
me), so I'd suggest sending it in the second half of the 4.7 merge
window (or about that time).

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1399552

On Wed, May 11, 2016 at 11:30 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 05/11/2016 02:22 PM, Rafael J. Wysocki wrote:
>>
>> On Wed, May 11, 2016 at 11:08 PM, David Daney <ddaney@caviumnetworks.com>
>> wrote:
>>>
>>> On 05/11/2016 01:35 PM, Rafael J. Wysocki wrote:
>>>>
>>>>
>>>> On Wed, May 11, 2016 at 12:40 PM, Will Deacon <will.deacon@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 27, 2016 at 8:07 PM, David Daney <ddaney.cavm@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> From: David Daney <david.daney@cavium.com>
>>>>>>>
>>>>>>> Based on
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>>>>>>> for-next/core branch at commit 643d703d2d2d ("arm64: compat: Check
>>>>>>> for
>>>>>>> AArch32 state")
>>>>>
>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>>> David Daney (2):
>>>>>>>     arm64, numa: Cleanup NUMA disabled messages.
>>>>>>>     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 (1):
>>>>>>>     acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
>>>>>>
>>>>>>
>>>>>>
>>>>>> I need ACKs from the ARM64 maintainers on patches [6-7/13] and
>>>>>> [13-14/14].
>>>>>
>>>>>
>>>>>
>>>>> There's also a dependency on the arm64 for-next/core branch, so I've
>>>>> been
>>>>> largely ignoring this as far as 4.6 is concerned and was planning to
>>>>> take
>>>>> a proper look for 4.7 once the upcoming merge window is out of the way.
>>>>
>>>>
>>>>
>>>> That would be 4.7 and 4.8 respectively I suppose?
>>>>
>>>> Anyway, Catalin has ACKed all of them except for the [13/14], so
>>>> technically I can apply [1-12/14] now and then [13-14/14] can be
>>>> applied when they are ready.
>>>>
>>>> Do you think there will be any problems with merging [6-7/14] into 4.7
>>>> via the ACPI tree?
>>>>
>>>
>>> I would defer to the arm64 maintainers for decisions about the arm64
>>> specific parts of the patch set.  That said, many of the arm64 specific
>>> patches depend on the arm64 for-next/core branch, so you would have to be
>>> careful about merge ordering if you pull these in before the
>>> for-next/core
>>> branch is merged.
>>
>>
>> Fair enough.  I will wait for an update then.
>>
>>> Also FWIW, I plan on addressing Catalin's comments about 13/14 and
>>> posting a
>>> new version of the patch set in the next day or two.
>>
>>
>> OK, but in that case it won't be considered for 4.7 (at least not by
>> me), so I'd suggest sending it in the second half of the 4.7 merge
>> window (or about that time).
>
>
> To be candid, I would very much like for you to pull in as many of the
> patches as you are comfortable with as soon as possible.
>
> I don't know where Will and Catalin stand on this, and their opinion is
> obviously important, but getting 1-12/14 merged to v4.7 and deferring the
> last two for v4.8 would simplify the whole process for me.  The drawback is
> carrying dead code around until the final parts are merged.

That is not unheard of, however.

OK, I'll try to put the [1-12/14] into my linux-next branch early next
week and we'll see if that triggers any conflicts.

[toc] | [prev] | [next] | [standalone]

#1399790

On Thu, May 12, 2016 at 12:29:02AM +0200, Rafael J. Wysocki wrote:
> On Wed, May 11, 2016 at 11:30 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> > On 05/11/2016 02:22 PM, Rafael J. Wysocki wrote:
> >> On Wed, May 11, 2016 at 11:08 PM, David Daney <ddaney@caviumnetworks.com>
> >> wrote:
> >>> On 05/11/2016 01:35 PM, Rafael J. Wysocki wrote:
> >>>> On Wed, May 11, 2016 at 12:40 PM, Will Deacon <will.deacon@arm.com>
> >>>> wrote:
> >>>>> On Wed, May 11, 2016 at 02:43:11AM +0200, Rafael J. Wysocki wrote:
> >>>>> There's also a dependency on the arm64 for-next/core branch, so I've
> >>>>> been
> >>>>> largely ignoring this as far as 4.6 is concerned and was planning to
> >>>>> take
> >>>>> a proper look for 4.7 once the upcoming merge window is out of the way.
> >>>>
> >>>>
> >>>>
> >>>> That would be 4.7 and 4.8 respectively I suppose?

Argh, yes, of course! :)

> >>>>
> >>>> Anyway, Catalin has ACKed all of them except for the [13/14], so
> >>>> technically I can apply [1-12/14] now and then [13-14/14] can be
> >>>> applied when they are ready.
> >>>>
> >>>> Do you think there will be any problems with merging [6-7/14] into 4.7
> >>>> via the ACPI tree?
> >>>>
> >>>
> >>> I would defer to the arm64 maintainers for decisions about the arm64
> >>> specific parts of the patch set.  That said, many of the arm64 specific
> >>> patches depend on the arm64 for-next/core branch, so you would have to be
> >>> careful about merge ordering if you pull these in before the
> >>> for-next/core
> >>> branch is merged.
> >>
> >>
> >> Fair enough.  I will wait for an update then.
> >>
> >>> Also FWIW, I plan on addressing Catalin's comments about 13/14 and
> >>> posting a
> >>> new version of the patch set in the next day or two.
> >>
> >>
> >> OK, but in that case it won't be considered for 4.7 (at least not by
> >> me), so I'd suggest sending it in the second half of the 4.7 merge
> >> window (or about that time).
> >
> >
> > To be candid, I would very much like for you to pull in as many of the
> > patches as you are comfortable with as soon as possible.
> >
> > I don't know where Will and Catalin stand on this, and their opinion is
> > obviously important, but getting 1-12/14 merged to v4.7 and deferring the
> > last two for v4.8 would simplify the whole process for me.  The drawback is
> > carrying dead code around until the final parts are merged.
> 
> That is not unheard of, however.
> 
> OK, I'll try to put the [1-12/14] into my linux-next branch early next
> week and we'll see if that triggers any conflicts.

I'd really much rather this waited until after the merge window. My
understanding is that it's bad practice to put stuff into -next during the
merge window, and you'd end up having to send a pull based on a random
commit (the arm64 pull request?) in the second half. On top of that, this
series would get very little exposure in -next during that time.

On the other hand, putting this into linux-next after the merge window
gives us time for testing, allows David to rework patch 13 (which is aiming
for 4.8 anyway iiuc) and avoids merge window churn.

Will

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web