11-07-2019, 10:29 PM
(11-07-2019, 10:07 PM)fire219 Wrote:Quote:- In the default OS there is a a frequency regulator in the main panel. I've never seen a menu like this before on any other machine, but it seems potentially quite useful. In particular I'd like to do performance benchmarks of some software I'm working on and I'd like to avoid external factors like thermal throttling, "turbo" modes and whatnot, so running slower but consistent would be very useful for getting repeatable results- however there is not a lot of info in the Help menu. The different profiles don't have any explanation and I'm unclear on what will happen if I manually select a high frequency. Will this risk overheating and damaging the computer?
The "profiles" in that regulator widget are standard Linux kernel "governors". You could look them up if you want exact details, but basically:
- "on-demand" is the best all around (performance when its needed, low power when its not)
- "performance" runs all the cores at full clock speed all the time. It won't damage anything, but the PBP will get noticeably hotter.
- "powersave" runs all the cores at their lowest clock speed. The benefits and downsides of this should be obvious.
Quote:There is also the whole "big-little" architecture and I'm not sure how scheduling happens for that - is there some place I can find more info? Maybe a way to temporarily disable the little cores when running certain jobs?
I'm not sure how the scheduling happens either. It depends on how the kernel is set up. There should be a way to disable the little cores but I'm not sure how -- and I wouldn't recommend it either. At worst, it messes with benchmarks. But the little cores are there for a reason: they consume a lot less power than the big cores, when you don't need full performance!
That's not an answer but a remark.
It is the first time I can toy around with big.little CPU architecture. Here is an interesting case-study in parallelization. I was compiling a linux kernel with make -jn allowing n compilations to be dispatched in parallel.
j1 real 63m03.721s user 64m20.015s sys 04m34.679s
j2 real 33m28.409s user 64m12.669s sys 04m50.640s
j3 real 27m14.206s user 73m06.491s sys 05m26.390s
j4 real 23m42.549s user 81m01.083s sys 06m02.435s
j5 real 21m58.216s user 88m57.846s sys 06m34.789s
j6 real 20m49.394s user 94m48.045s sys 06m51.734s
The data is very interesting:
- With one core, we have real < user + sys. Maybe some sys work got dispatched in parallel to user work. dpkg-deb builds the kernel packages after the actual compilation is multi-threaded resulting in utilization of multiple cores.
- user and sys time stay the same when the compilation is dispatched on one or on two equally fast cores. Real time halves.
- when slower cores join the compilation (j3 - j6), real time continues to drop, but user and sys times increase.
PS: you can configure your cpus via sysfs callback under sys/devices/system/cpu/ - look around and cat and echo values.
