Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 07/12/15 13:18, Russell King - ARM Linux wrote: > On Mon, Dec 07, 2015 at 12:36:54PM +, Juri Lelli wrote: > > On 07/12/15 12:11, Russell King - ARM Linux wrote: > > > It looks like the second patch doesn't yet have the backing from the DT > > > people, which prevents the remainder of the patch set progressing. That's > > > the sticking point which needs to be resolved. > > > > > > > Agreed. That is exactly the point for which I was seeking more feedback. > > OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they > > simply expose a sysfs attribute. If you, and others, see value in them, > > I can easily put them at the top of the series and post a v2. Thoughts? > > I've no idea, sorry. When it comes to stuff like CPU level power > management, the hardware I have is very limited in its capabilities > (no support even for S2RAM.) I've also never managed to get > big.LITTLE working on my platforms that should support it. > No problem. Thanks a lot for your feedback anyway. > Eg, I gave up with the TC2 tile in Versatile Express. I forget the > details, but getting it booting was exceedingly difficult, and no one > really seemed interested in helping. So my TC2 tile is collecting > dust while the CA9x4 tile lives in the platform - which is now part of > the nightly build/boot test farm. > I guess I could provide some support for the TC2 bits, if you didn't yet give up completely on it :-). Please, don't hesitate to let me know, even privately, about that. Best, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On Mon, Dec 07, 2015 at 12:36:54PM +, Juri Lelli wrote: > On 07/12/15 12:11, Russell King - ARM Linux wrote: > > It looks like the second patch doesn't yet have the backing from the DT > > people, which prevents the remainder of the patch set progressing. That's > > the sticking point which needs to be resolved. > > > > Agreed. That is exactly the point for which I was seeking more feedback. > OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they > simply expose a sysfs attribute. If you, and others, see value in them, > I can easily put them at the top of the series and post a v2. Thoughts? I've no idea, sorry. When it comes to stuff like CPU level power management, the hardware I have is very limited in its capabilities (no support even for S2RAM.) I've also never managed to get big.LITTLE working on my platforms that should support it. Eg, I gave up with the TC2 tile in Versatile Express. I forget the details, but getting it booting was exceedingly difficult, and no one really seemed interested in helping. So my TC2 tile is collecting dust while the CA9x4 tile lives in the platform - which is now part of the nightly build/boot test farm. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 07/12/15 12:11, Russell King - ARM Linux wrote: > On Mon, Dec 07, 2015 at 12:02:44PM +, Juri Lelli wrote: > > On 23/11/15 14:28, Juri Lelli wrote: > > > Hi all, > > > > > > > Hi again everybody, > > > > thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more > > discussion happening on this series to figure out how we move forward; > > so, this is a ping :-). It's a simple information that we need to figure > > out how to provide, and in which form, but it has the potential to form > > a standardized basis for achieving important performance benefits. > > I'm happy to take the first patch, it looks like a simple clean up. > Please arrange for it to land in my patch system. Thanks. > OK, will do. Thanks! > It looks like the second patch doesn't yet have the backing from the DT > people, which prevents the remainder of the patch set progressing. That's > the sticking point which needs to be resolved. > Agreed. That is exactly the point for which I was seeking more feedback. OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they simply expose a sysfs attribute. If you, and others, see value in them, I can easily put them at the top of the series and post a v2. Thoughts? Best, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On Mon, Dec 07, 2015 at 12:02:44PM +, Juri Lelli wrote: > On 23/11/15 14:28, Juri Lelli wrote: > > Hi all, > > > > Hi again everybody, > > thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more > discussion happening on this series to figure out how we move forward; > so, this is a ping :-). It's a simple information that we need to figure > out how to provide, and in which form, but it has the potential to form > a standardized basis for achieving important performance benefits. I'm happy to take the first patch, it looks like a simple clean up. Please arrange for it to land in my patch system. Thanks. It looks like the second patch doesn't yet have the backing from the DT people, which prevents the remainder of the patch set progressing. That's the sticking point which needs to be resolved. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 23/11/15 14:28, Juri Lelli wrote: > Hi all, > Hi again everybody, thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more discussion happening on this series to figure out how we move forward; so, this is a ping :-). It's a simple information that we need to figure out how to provide, and in which form, but it has the potential to form a standardized basis for achieving important performance benefits. Thanks, - Juri > ARM systems may be configured to have CPUs with different power/performance > characteristics within the same chip. In this case, additional information has > to be made available to the kernel (the scheduler in particular) for it to be > aware of such differences and take decisions accordingly. This posting stems > from the ongoing discussion about introducing a simple platform energy cost > model to guide scheduling decisions (a.k.a Energy Aware Scheduling [1]), but > also aims to be an independent track aimed to standardise the way we make the > scheduler aware of heterogenous CPU systems. With these patches and in > addition > patches from [1] (that make the scheduler wakeup paths aware of heterogenous > CPU systems) we enable the scheduler to have good default performance on such > systems. In addition, we get a clearly defined way of providing the scheduler > with needed information about CPU capacity on such systems. > > CPU capacity is defined in this context as a number that provides the > scheduler > information about CPUs heterogeneity. Such heterogeneity can come from > micro-architectural differences (e.g., ARM big.LITTLE systems) or maximum > frequency at which CPUs can run (e.g., SMP systems with multiple frequency > domains and different max frequencies). Heterogeneity in this context is about > differing performance characteristics; in practice, the binding that we > propose > in this RFC tries to capture a first-order approximation of the relative > performance of CPUs. > > This RFC proposes a solution to the problem of how do we init CPUs original > capacity. The way it works today, and for arm A15/A7 systems only, is that we > rely on cpu_efficiency magic numbers from arch/arm/kernel/topology.c and the > existence of clock-frequency dtb properties; having those values available, we > then do some math to come up with capacities we know from measurement (e.g., > EAS energy model), e.g. for TC2 they are 430 for A7 and 1024 for A15. > Currently, arm64 doesn't have such a feature at all. > > With this patchset we provide CPUs capacity information either from DT or from > sysfs interface. Such information is standardized for both arm and arm64. > > Patches high level description: > > o 01/08 cleans up how cpu_scale is initialized in arm > o 02/08 introduces documentation for the new optional DT binding > o [03-06]/08 add cpu-capacity attribute to TC2 and Juno DTs and provide >parsing of such information at boot time > o [07-08]/08 introduce sysfs attribute > > The patchset is based on top of tip/sched/core as of today. > > In case you would like to test this out, I pushed a branch here: > > git://linux-arm.org/linux-jl.git upstream/default_caps_dt > > This branch contains additional patches, useful to better understand how CPU > capacity information is actually used by the scheduler. Discussion regarding > these additional patches will be started with a different posting in the > future. We just didn't want to make discussion too broad, as we realize that > this set can be controversial already on its own. > > Comments, concerns and rants are more than welcome! > > Best, > > - Juri > > Juri Lelli (8): > ARM: initialize cpu_scale to its default > Documentation: arm: define DT cpu capacity bindings > arm: parse cpu capacity from DT > arm, dts: add TC2 cpu capacity information > arm64: parse cpu capacity from DT > arm64, dts: add Juno cpu capacity information > arm: add sysfs cpu_capacity attribute > arm64: add sysfs cpu_capacity attribute > > .../devicetree/bindings/arm/cpu-capacity.txt | 227 > + > Documentation/devicetree/bindings/arm/cpus.txt | 17 ++ > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 6 + > arch/arm/kernel/topology.c | 122 ++- > arch/arm64/boot/dts/arm/juno.dts | 7 + > arch/arm64/kernel/topology.c | 114 +++ > 6 files changed, 489 insertions(+), 4 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt > > -- > 2.2.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 07/12/15 13:18, Russell King - ARM Linux wrote: > On Mon, Dec 07, 2015 at 12:36:54PM +, Juri Lelli wrote: > > On 07/12/15 12:11, Russell King - ARM Linux wrote: > > > It looks like the second patch doesn't yet have the backing from the DT > > > people, which prevents the remainder of the patch set progressing. That's > > > the sticking point which needs to be resolved. > > > > > > > Agreed. That is exactly the point for which I was seeking more feedback. > > OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they > > simply expose a sysfs attribute. If you, and others, see value in them, > > I can easily put them at the top of the series and post a v2. Thoughts? > > I've no idea, sorry. When it comes to stuff like CPU level power > management, the hardware I have is very limited in its capabilities > (no support even for S2RAM.) I've also never managed to get > big.LITTLE working on my platforms that should support it. > No problem. Thanks a lot for your feedback anyway. > Eg, I gave up with the TC2 tile in Versatile Express. I forget the > details, but getting it booting was exceedingly difficult, and no one > really seemed interested in helping. So my TC2 tile is collecting > dust while the CA9x4 tile lives in the platform - which is now part of > the nightly build/boot test farm. > I guess I could provide some support for the TC2 bits, if you didn't yet give up completely on it :-). Please, don't hesitate to let me know, even privately, about that. Best, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 07/12/15 12:11, Russell King - ARM Linux wrote: > On Mon, Dec 07, 2015 at 12:02:44PM +, Juri Lelli wrote: > > On 23/11/15 14:28, Juri Lelli wrote: > > > Hi all, > > > > > > > Hi again everybody, > > > > thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more > > discussion happening on this series to figure out how we move forward; > > so, this is a ping :-). It's a simple information that we need to figure > > out how to provide, and in which form, but it has the potential to form > > a standardized basis for achieving important performance benefits. > > I'm happy to take the first patch, it looks like a simple clean up. > Please arrange for it to land in my patch system. Thanks. > OK, will do. Thanks! > It looks like the second patch doesn't yet have the backing from the DT > people, which prevents the remainder of the patch set progressing. That's > the sticking point which needs to be resolved. > Agreed. That is exactly the point for which I was seeking more feedback. OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they simply expose a sysfs attribute. If you, and others, see value in them, I can easily put them at the top of the series and post a v2. Thoughts? Best, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On 23/11/15 14:28, Juri Lelli wrote: > Hi all, > Hi again everybody, thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more discussion happening on this series to figure out how we move forward; so, this is a ping :-). It's a simple information that we need to figure out how to provide, and in which form, but it has the potential to form a standardized basis for achieving important performance benefits. Thanks, - Juri > ARM systems may be configured to have CPUs with different power/performance > characteristics within the same chip. In this case, additional information has > to be made available to the kernel (the scheduler in particular) for it to be > aware of such differences and take decisions accordingly. This posting stems > from the ongoing discussion about introducing a simple platform energy cost > model to guide scheduling decisions (a.k.a Energy Aware Scheduling [1]), but > also aims to be an independent track aimed to standardise the way we make the > scheduler aware of heterogenous CPU systems. With these patches and in > addition > patches from [1] (that make the scheduler wakeup paths aware of heterogenous > CPU systems) we enable the scheduler to have good default performance on such > systems. In addition, we get a clearly defined way of providing the scheduler > with needed information about CPU capacity on such systems. > > CPU capacity is defined in this context as a number that provides the > scheduler > information about CPUs heterogeneity. Such heterogeneity can come from > micro-architectural differences (e.g., ARM big.LITTLE systems) or maximum > frequency at which CPUs can run (e.g., SMP systems with multiple frequency > domains and different max frequencies). Heterogeneity in this context is about > differing performance characteristics; in practice, the binding that we > propose > in this RFC tries to capture a first-order approximation of the relative > performance of CPUs. > > This RFC proposes a solution to the problem of how do we init CPUs original > capacity. The way it works today, and for arm A15/A7 systems only, is that we > rely on cpu_efficiency magic numbers from arch/arm/kernel/topology.c and the > existence of clock-frequency dtb properties; having those values available, we > then do some math to come up with capacities we know from measurement (e.g., > EAS energy model), e.g. for TC2 they are 430 for A7 and 1024 for A15. > Currently, arm64 doesn't have such a feature at all. > > With this patchset we provide CPUs capacity information either from DT or from > sysfs interface. Such information is standardized for both arm and arm64. > > Patches high level description: > > o 01/08 cleans up how cpu_scale is initialized in arm > o 02/08 introduces documentation for the new optional DT binding > o [03-06]/08 add cpu-capacity attribute to TC2 and Juno DTs and provide >parsing of such information at boot time > o [07-08]/08 introduce sysfs attribute > > The patchset is based on top of tip/sched/core as of today. > > In case you would like to test this out, I pushed a branch here: > > git://linux-arm.org/linux-jl.git upstream/default_caps_dt > > This branch contains additional patches, useful to better understand how CPU > capacity information is actually used by the scheduler. Discussion regarding > these additional patches will be started with a different posting in the > future. We just didn't want to make discussion too broad, as we realize that > this set can be controversial already on its own. > > Comments, concerns and rants are more than welcome! > > Best, > > - Juri > > Juri Lelli (8): > ARM: initialize cpu_scale to its default > Documentation: arm: define DT cpu capacity bindings > arm: parse cpu capacity from DT > arm, dts: add TC2 cpu capacity information > arm64: parse cpu capacity from DT > arm64, dts: add Juno cpu capacity information > arm: add sysfs cpu_capacity attribute > arm64: add sysfs cpu_capacity attribute > > .../devicetree/bindings/arm/cpu-capacity.txt | 227 > + > Documentation/devicetree/bindings/arm/cpus.txt | 17 ++ > arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 6 + > arch/arm/kernel/topology.c | 122 ++- > arch/arm64/boot/dts/arm/juno.dts | 7 + > arch/arm64/kernel/topology.c | 114 +++ > 6 files changed, 489 insertions(+), 4 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt > > -- > 2.2.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On Mon, Dec 07, 2015 at 12:02:44PM +, Juri Lelli wrote: > On 23/11/15 14:28, Juri Lelli wrote: > > Hi all, > > > > Hi again everybody, > > thanks a lot to Rob and Vincent for feedback, but, IMHO, we'd need more > discussion happening on this series to figure out how we move forward; > so, this is a ping :-). It's a simple information that we need to figure > out how to provide, and in which form, but it has the potential to form > a standardized basis for achieving important performance benefits. I'm happy to take the first patch, it looks like a simple clean up. Please arrange for it to land in my patch system. Thanks. It looks like the second patch doesn't yet have the backing from the DT people, which prevents the remainder of the patch set progressing. That's the sticking point which needs to be resolved. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] CPUs capacity information for heterogeneous systems
On Mon, Dec 07, 2015 at 12:36:54PM +, Juri Lelli wrote: > On 07/12/15 12:11, Russell King - ARM Linux wrote: > > It looks like the second patch doesn't yet have the backing from the DT > > people, which prevents the remainder of the patch set progressing. That's > > the sticking point which needs to be resolved. > > > > Agreed. That is exactly the point for which I was seeking more feedback. > OTOH, 7/8 and 8/8 may potentially work without the DT bindings, as they > simply expose a sysfs attribute. If you, and others, see value in them, > I can easily put them at the top of the series and post a v2. Thoughts? I've no idea, sorry. When it comes to stuff like CPU level power management, the hardware I have is very limited in its capabilities (no support even for S2RAM.) I've also never managed to get big.LITTLE working on my platforms that should support it. Eg, I gave up with the TC2 tile in Versatile Express. I forget the details, but getting it booting was exceedingly difficult, and no one really seemed interested in helping. So my TC2 tile is collecting dust while the CA9x4 tile lives in the platform - which is now part of the nightly build/boot test farm. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
