Hi,
On 22/03/18 16:33, Jason Cren wrote:
Hi, My first mail here, please tell me if this is not the right list for my queries.
You have knocked at the right door :)
I have recently got myself a thundersoft s835 development kit and set it up for power measurement. I was looking at creating the energy model for this from scratch and measuring the impact. I stumbled across something which led me to write this mail. The eas integration document mentions no support currently exists for SMT. However, my kernel configuration for some reason has SCHED_SMT enabled. The s835 is not hyper-threaded and so I am thinking it's a mistake. My questions are
- Is disabling SCHED_SMT enough or are there any other configurations that need to be changed as well ?
Regarding SCHED_SMT, if you have:
zcat /proc/config.z | grep SCHED_SMT
CONFIG_SCHED_SMT=y
Then that's not necessarily a wrong configuration. All this does is allow the SMT code to be compiled in the kernel ([1]) - if it is used depends on what is there at runtime ([2]). However, it is broken with EAS so you should disable it if you want to use EAS.
- I'd like to understand the technical difficulties with enabling SMT support since I have a mips device which has hyperthreading. Is it that the cpu-cluster energy model would not be enough to handle proper task placement when it comes to virtual cores ?
So I'm really not well versed in SMT but I think the biggest problem is that IIRC SMT adds another scheduler domain ((DIE, MC) + SMT).
Plus there are assumptions in EAS that make sense for big.LITTLE but not really for SMT: I recall that the capacity of two virtual cores is smaller than the capacity of the physical core they reside in, which can potentially mess up the heuristics that use capacity.
- Is there any on-going work on adding SMT support or is it considered as not being worth the effort ?
I know there's work being done on bugfixes, but that's to make the kernel not crash with SCHED_SMT (see my answer to 1), not to make EAS work on SMT HW. Beyond that I'm not the right person to ask, sorry :(
Thanks for reading. -Jason
Cheers, Valentin
[1]: https://android.googlesource.com/kernel/common/+/android-4.9/kernel/sched/fa... [2]:
That's where the topology code comes into play. Most of it is still somewhat obscure to me (the only cure is staring at it long enough really), but you can see that there are flags that say "my hardware has SMT": [3].
You can see the flags that are defined on your system by issuing:
cat /proc/sys/kernel/sched_domain/cpu*/domain*/flags
For instance, I get for my HiKey960:
cat /proc/sys/kernel/sched_domain/cpu0/domain*/flags
4671 4223
Flag values are defined in [4], and that lets me see that SD_ASYM_CPUCAPACITY is set for domain1 but not for domain0. We have some tests [5] that check those flags if you want to do a comparison with your setup.
[3]: https://android.googlesource.com/kernel/common/+/android-4.9/kernel/sched/co... [4]: https://android.googlesource.com/kernel/common/+/android-4.9/include/linux/s... [5]: https://github.com/mdigiorgio/lisa/blob/b9157d7d5b20a13c6e420ba2bb63e26f983a...