[Fire HD 8 and HD 10 Original Android Development] psi78:
Just did reproduce the high cpu temp in Power Saving mode though, weird (still same setup with nogapps, no magisk):

I switched the device on/did a cold boot, then forgot to use it, then returned to it after a while, switched screen back on and CPU core 2 and sometimes 3 where on high throttle again.

Then i did a reboot and the problem persisted. Temp was more mlike 60degrees Celsius tho.

Previously (with previous setups, especially after a fresh install) i think the device even powered down when i left it unattended for a while and Power Saving mode was off. I guess this could happen again when i'd switch power saving mode off.

I'm not totally sure, but i think the powering down of itself also disappeared in previous setups after i had installed naptime (which interacts with the power management of LOS). Or at least with the setup i mentioned in a previous post (rom version 20220413 with power saving on, data saving on, sync off, location off, naptime installed), and doing no reboots it kinda worked.

On fdroid there are also open source alternatives to naptime like Battery Tool or ForceDoze, so feel free to test these in conjunction with PowerSaving mode, to see if this is a workaround in the current state of the Rom. I don't know Battery Tool, demands root though, so have care.

Naptime and ForceDoze work also with permissions set per adb.

Edit:

As hypotheses (i may be wrong there in all points):

Assuming suez cpu cores 0 and 1 are A53 cpus and cores 2 and 3 are A72 cpus they seem to react differently, because the heavy cpu usage is mostly on cpu core 2 and sometimes 3.

So either compiled aarch64 code is not yet optimized for this cpu setup as gcc 4.9 supports not yet full optimization for big.little setup.

Or there's armv7 code which is compiled wrongly because cpu and arch is specified as cortex-a15 in the current device makefile BoardConfig.mk ( https://github.com/lineage16-suez/device_amazon_suez/blob/lineage-16.0/BoardConfig.mk)

Or legacy libs which are not optimized/too incompatible for the a72

Could be wrong there again, but I still think specifying cpu instead of arch for cross-compiling leads to the compiler setting up flags heavily specific for that cpu. But this a15 optimized code may not work properly on another cpu like a53 or a72 because the hardware is too different. So maybe a more fail-safe compiling of the 32bit stuff would be to specify only arch and not cpu or leave cpu generic?

See also

conflicts between cpu and arch while building

I have a doubht regarding mcpu and march options of gcc. In my setup the environment variables are using -mcpu=cortex-a7 and -march=armv7ve, while building application getting the following error. ...

stackoverflow.com

and comparisons of arm processor architecture

Comparison of ARM processors - Wikipedia

en.m.wikipedia.org

Comparison of ARM processors - Wikipedia

en.m.wikipedia.org

Oh well, complicated. But maybe the fix that MarvinMod mentioned already is enough.

Edit2: Is there even true multithreading of a process on android/with this gcc version i'm wondering, don't really have a clue there, sorry. Because lets assume if a process at startup gets randomly executed by one of the cpu's, and its load isn't distributed evenly to all cores, but only executed by the one cpu it was executed by first -then it would explain why a fix like executing all processes at startup by only one cpu core works🤔