| Message ID | 20190627195302.28300-1-atish.patra@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Unify CPU topology across ARM & RISC-V | expand |
Hi Atish Looks like patches 1, 6, and 7 are missing your Signed-off-by:. Can I add those? - Paul
On Mon, 2019-07-01 at 11:44 -0700, Paul Walmsley wrote: > Hi Atish > > Looks like patches 1, 6, and 7 are missing your Signed-off-by:. Can > I add > those? > Sure. Is it a common practice to add "Signed-off-by:" the sender even if the sender has not touched the patch at all? Regards, Atish > > - Paul
On Mon, 1 Jul 2019, Atish Patra wrote: > On Mon, 2019-07-01 at 11:44 -0700, Paul Walmsley wrote: > > > > Looks like patches 1, 6, and 7 are missing your Signed-off-by:. Can I > > add those? > > > Sure. > > Is it a common practice to add "Signed-off-by:" the sender even if the > sender has not touched the patch at all? Yes, see section 11(c) here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n418 The main factor here is that you collected and resent the patches - thus you're in the patch submission chain. - Paul
On Mon, 2019-07-01 at 11:55 -0700, Paul Walmsley wrote: > On Mon, 1 Jul 2019, Atish Patra wrote: > > > On Mon, 2019-07-01 at 11:44 -0700, Paul Walmsley wrote: > > > Looks like patches 1, 6, and 7 are missing your Signed-off- > > > by:. Can I > > > add those? > > > > > Sure. > > > > Is it a common practice to add "Signed-off-by:" the sender even if > > the > > sender has not touched the patch at all? > > Yes, see section 11(c) here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n418 > > The main factor here is that you collected and resent the patches - > thus > you're in the patch submission chain. > Ahh okay. Thanks for the link. I will keep this in mind in future. Regards, Atish > > - Paul
Folks, On Thu, 27 Jun 2019, Atish Patra wrote: > The cpu-map DT entry in ARM can describe the CPU topology in much better > way compared to other existing approaches. RISC-V can easily adopt this > binding to represent its own CPU topology. Thus, both cpu-map DT > binding and topology parsing code can be moved to a common location so > that RISC-V or any other architecture can leverage that. > > The relevant discussion regarding unifying cpu topology can be found in > [1]. > > arch_topology seems to be a perfect place to move the common code. I > have not introduced any significant functional changes in the moved code. > The only downside in this approach is that the capacity code will be > executed for RISC-V as well. But, it will exit immediately after not > able to find the appropriate DT node. If the overhead is considered too > much, we can always compile out capacity related functions under a > different config for the architectures that do not support them. > > There was an opportunity to unify topology data structure for ARM32 done > by patch 3/4. But, I refrained from making any other changes as I am not > very well versed with original intention for some functions that > are present in arch_topology.c. I hope this patch series can be served > as a baseline for such changes in the future. > > The patches have been tested for RISC-V, ARM64, ARM32 & compile tested for > x86. Since these patches touch files across several different architectures, and thus really should sit in -next for a while; and because it's late in the merge window, I'm planning to postpone sending these patches upstream until after v5.3-rc1 is released. Once v5.3-rc1 is released, let's plan to get these patches rebased and reposted and into linux-next as soon as possible. Sorry for the delay here, - Paul
On Fri, 12 Jul 2019, Paul Walmsley wrote: > On Thu, 27 Jun 2019, Atish Patra wrote: > > > The cpu-map DT entry in ARM can describe the CPU topology in much better > > way compared to other existing approaches. RISC-V can easily adopt this > > binding to represent its own CPU topology. Thus, both cpu-map DT > > binding and topology parsing code can be moved to a common location so > > that RISC-V or any other architecture can leverage that. > > different config for the architectures that do not support them. > > Once v5.3-rc1 is released, let's plan to get these patches rebased and > reposted and into linux-next as soon as possible. These CPU topology patches are now queued for v5.4-rc1. They should enter linux-next shortly. - Paul
On 7/22/19 12:25 PM, Paul Walmsley wrote: > On Fri, 12 Jul 2019, Paul Walmsley wrote: > >> On Thu, 27 Jun 2019, Atish Patra wrote: >> >>> The cpu-map DT entry in ARM can describe the CPU topology in much better >>> way compared to other existing approaches. RISC-V can easily adopt this >>> binding to represent its own CPU topology. Thus, both cpu-map DT >>> binding and topology parsing code can be moved to a common location so >>> that RISC-V or any other architecture can leverage that. >>> different config for the architectures that do not support them. >> >> Once v5.3-rc1 is released, let's plan to get these patches rebased and >> reposted and into linux-next as soon as possible. > > These CPU topology patches are now queued for v5.4-rc1. They should enter > linux-next shortly. > > > - Paul > Thanks!!
The cpu-map DT entry in ARM can describe the CPU topology in much better way compared to other existing approaches. RISC-V can easily adopt this binding to represent its own CPU topology. Thus, both cpu-map DT binding and topology parsing code can be moved to a common location so that RISC-V or any other architecture can leverage that. The relevant discussion regarding unifying cpu topology can be found in [1]. arch_topology seems to be a perfect place to move the common code. I have not introduced any significant functional changes in the moved code. The only downside in this approach is that the capacity code will be executed for RISC-V as well. But, it will exit immediately after not able to find the appropriate DT node. If the overhead is considered too much, we can always compile out capacity related functions under a different config for the architectures that do not support them. There was an opportunity to unify topology data structure for ARM32 done by patch 3/4. But, I refrained from making any other changes as I am not very well versed with original intention for some functions that are present in arch_topology.c. I hope this patch series can be served as a baseline for such changes in the future. The patches have been tested for RISC-V, ARM64, ARM32 & compile tested for x86. From Jeremy, "I applied these to 5.2rc2, along with my PPTT/MT change and verified the system & scheduler topology/etc on DAWN and ThunderX2 using ACPI on arm64. They appear to be working correctly. so for the series, Tested-by: Jeremy Linton <jeremy.linton@arm.com>" The socket change[2] is also now part of this series. [1] https://lkml.org/lkml/2018/11/6/19 [2] https://lkml.org/lkml/2018/11/7/918 This patch series can also be found at https://github.com/atishp04/linux/tree/5.2-rc6_topology QEMU changes for RISC-V topology are available here https://lists.nongnu.org/archive/html/qemu-devel/2019-06/msg05974.html HiFive Unleashed DT with topology node is available here. https://patchwork.kernel.org/patch/11014313/ Changes from v7->v8 1. Regenerated the patch series without -b option in git format-patch. Without that, git apply from email won't work because ignored space changes. Changes from v6->v7 1. Added socket to HiFive Unleashed topology example. 2. Added Acked-by & Reviewed-by. Changes from v5->v6 1. Added two more patches from Sudeep about maintainership of arch_topology.c and Kconfig update. 2. Added Tested-by & Reviewed-by 3. Fixed a nit (reordering of variables) Changes from v4-v5 1. Removed the arch_topology.h header inclusion from topology.c and arch_topology.c file. Added it in linux/topology.h. 2. core_id is set to -1 upon reset. Otherwise, ARM topology store function does not work. Changes from v3->v4 1. Get rid of ARM32 specific information in topology structure. 2. Remove redundant functions from ARM32 and use common code instead. Changes from v2->v3 1. Cover letter update with experiment DT for topology changes. 2. Added the patch for [2]. Changes from v1->v2 1. ARM32 can now use the common code as well. Atish Patra (4): dt-binding: cpu-topology: Move cpu-map to a common binding. cpu-topology: Move cpu topology code to common code. arm: Use common cpu_topology structure and functions. RISC-V: Parse cpu topology during boot. Sudeep Holla (3): Documentation: DT: arm: add support for sockets defining package boundaries base: arch_topology: update Kconfig help description MAINTAINERS: Add an entry for generic architecture topology .../topology.txt => cpu/cpu-topology.txt} | 256 ++++++++++----- MAINTAINERS | 7 + arch/arm/include/asm/topology.h | 20 -- arch/arm/kernel/topology.c | 60 +--- arch/arm64/include/asm/topology.h | 23 -- arch/arm64/kernel/topology.c | 303 +----------------- arch/riscv/Kconfig | 1 + arch/riscv/kernel/smpboot.c | 3 + drivers/base/Kconfig | 2 +- drivers/base/arch_topology.c | 298 +++++++++++++++++ include/linux/arch_topology.h | 26 ++ include/linux/topology.h | 1 + 12 files changed, 514 insertions(+), 486 deletions(-) rename Documentation/devicetree/bindings/{arm/topology.txt => cpu/cpu-topology.txt} (66%) -- 2.21.0