[Bug]: One UI 8.x: big CPU cores are never used in tested Termux/proot workloads

[hansm629]

Problem description

Hello,

I would like to report a possible performance regression affecting Termux on Samsung Galaxy devices running One UI 8.x.

Issue:
On One UI 8.x, tested heavy native workloads launched from Termux no longer use the big CPU cluster properly.
In my testing, the big-core cluster does not show utilization at all.

1. One UI 7.0

2. One UI 8.x

Steps to reproduce the behavior.

Test environment:

• Termux bionic build of Shotcut
• 4K@30fps video rendering workload
• Termux 0.119.0-beta.3/ Termux-X11 environment
• Additional verification with Geekbench inside a proot container

Observed behavior by device during Shotcut video rendering:

Galaxy S21 Ultra (Exynos 2100)

• One UI 7.0:
  CPU cores 0 through 7 show utilization during rendering.
  All 8 CPU cores are used correctly.

Galaxy S24+ (Exynos 2400)

• One UI 7.0:
  CPU cores 0 through 9 show utilization during rendering.
  All 10 CPU cores are used correctly.
• One UI 8.0 / 8.5(Beta):
  CPU cores 0 through 8 show utilization during rendering.
  Only 9 CPU cores are used.
  The big-core cluster shows no utilization.

Galaxy S24 Ultra (Snapdragon 8 Gen 3)

• One UI 7.0:
  CPU cores 0 through 7 show utilization during rendering.
  All 8 CPU cores are used correctly.

Galaxy S25 Ultra (Snapdragon 8 Elite)

• One UI 8.5(Beta):
  CPU cores 0 through 5 show utilization during rendering.
  Only 6 CPU cores are used.
  The big-core cluster shows no utilization.

Galaxy S26 Ultra (Snapdragon 8 Elite Gen5)

• One UI 8.5:
  CPU cores 0 through 5 show utilization during rendering.
  Only 6 CPU cores are used.
  The big-core cluster shows no utilization.

Galaxy Tab S9 Ultra (Snapdragon 8 Gen2)

• One UI 8.0:
  CPU cores 0 through 6 show utilization during rendering.
  Only 7 CPU cores are used.
  The big-core cluster shows no utilization.

What is the expected behavior?

Additional observation:
On One UI 8.0 / 8.5, I could not observe any utilization of the big-core cluster in any tested Termux or proot workload, not just during video rendering.

Additional verification:

• Geekbench inside a proot container also appears to be affected on One UI 8.5.
• I also tested Good Lock Game Booster+ by adding Termux as a game app and setting CPU/GPU to maximum performance, but it did not change this behavior.

Why this seems important:
This does not look like a Shotcut-only issue.
It appears to affect Termux native/proot workloads more broadly on One UI 8.x.

Possible cause:
This may be related to changed task classification, scheduler behavior, cpuset/cgroup assignment, or power policy on One UI 8.x.

Please let me know if there is any debugging information I can provide.
Thank you.

System information

• Termux application version: Termux 0.119.0-beta.3
• Android OS version: One UI 8.x(Android 16) / One UI 7.0(Android 15)
• Device model: Galaxy S21 Ultra / Galaxy S24+ / Galaxy S24 Ultra / Galaxy S25 Ultra / Galaxy S26 Ultra / Galaxy Tab S9 Ultra

[ferrumclaudepilgrim]

Hey -- ran this on my S26 Ultra and couldn't reproduce. Wanted to share what I found.

Device: Samsung Galaxy S26 Ultra (SM-S938U), Snapdragon 8 Elite, Android 16, One UI 8.x, Termux from F-Droid

Test 1 -- single-threaded, ran it 5 times:

node -e "let s=Date.now(); while(Date.now()-s<3000){Math.random()*Math.random()}" &
PID=$!; sleep 2; awk '{print $39}' /proc/$PID/stat

Results: CPU 6, CPU 7, CPU 7, CPU 6, CPU 7. All 5 landed on the prime cores.

Test 2 -- 8 parallel workers, one per core:

for i in 0 1 2 3 4 5 6 7; do
  node -e "let s=Date.now(); while(Date.now()-s<5000){Math.random()*Math.random()}" &
done
sleep 2
# Checked CPU assignment via field 39 in each PID's stat file

Worker 0: CPU 1
Worker 1: CPU 6
Worker 2: CPU 4
Worker 3: CPU 2
Worker 4: CPU 3
Worker 5: CPU 5
Worker 6: CPU 7
Worker 7: CPU 6

All 8 cores active. Prime cores (cpu6/cpu7) at 3.86 GHz, efficiency cores at 3.4-3.5 GHz under load. cpuset was /top-app, affinity mask ff.

I also toggled "Disable child process restrictions" back ON (re-enabled the restriction) and reran Test 2. Big cores still got used, but frequencies dropped across the board -- efficiency down to 2.75 GHz, prime down to 2.67 GHz. Cores 6/7 did not go to 0% like in your screenshots though.

My developer options that might matter:

• Disable child process restrictions: ON (disabled the restriction)
• Battery optimization: OFF for Termux
• Battery saver: OFF
• Adaptive battery: OFF

All testing was done in native Termux, not proot.

I noticed you have the S26 Ultra listed as affected in your table. Is yours the Snapdragon or Exynos variant? Mine's Snapdragon (SM-S938U). Wondering if this is Exynos-specific or if the developer options / battery settings are the differentiator. Would be curious to know your config.

[hansm629]

@ferrumclaudepilgrim
Hello sir!
Thank you for checking!

Through recent testing, I have identified the cause of the symptom.
It turns out that when the Termux app is in the background, it does not use the Big Core cluster at all!

If I run Termux-X11 via the xfce4 command from the Termux app,

the Termux app goes into the background, and in that case, the Big Cores do not operate.
If I switch back to the Termux app and then switch back to Termux-X11 in this state,

the Big Cores remain active for about 40 seconds to 1 minute.
If I switch entirely to the Termux app while video is rendering,
all cores are used until rendering is complete, and the usage rate reaches 92–98%.

It appears that starting with OneUI 8.x, the CPU workload policy
does not use the Big Core cluster when the app is in the background.
(It might also be an Android 16 policy.)

Is it possible to modify the app so that the Big Core cluster operates even in the background?

[ferrumclaudepilgrim]

Follow-up -- was able to reproduce after all. Turns out my first test was foreground-only which is why I didn't see it.

What I'm seeing when Termux goes to background:

	Foreground	Background
cpuset	/top-app	/moderate
affinity mask	ff (all 8 cores)	33 (cpu0-1, cpu4-5 only)
big core freq	3.6-4.7 GHz	883 MHz (idle)

Looks like the instant you switch away from Termux, Android moves the process from /top-app to /moderate and rewrites the affinity mask to exclude the prime cores. Happens within about a second of switching apps.

Tried two things to get around it -- neither worked:

1. termux-wake-lock -- grabbed it before backgrounding. Didn't help. Seems like wake-lock keeps the CPU awake but doesn't keep the app in /top-app.

2. taskset pinning to cpu6/7 -- pinned the process before backgrounding. Android just overwrote the pin when it moved the process to /moderate.

How I tested (if anyone wants to reproduce):

node -e "let s=Date.now(); while(Date.now()-s<90000){Math.random()*Math.random()}" &
NODEPID=$!

# Logged every second: cpuset, affinity, core assignment, frequency
# Switched away from Termux for 20s, came back, repeated
# Fields from /proc/$NODEPID/cpuset, taskset -p, stat field 39,
# and /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

Haven't tried yet: whether ADB shell can write processes back into the /top-app cpuset while backgrounded. Might be worth looking into for anyone with wireless debugging enabled. No idea if it would stick or if Android would just overwrite it again though.

[hansm629]

@ferrumclaudepilgrim
Thank you for checking this!

Since I do not experience this symptom on my OneUI 7 device regardless of the AP SoC,

it seems that the CPU workload policy for background apps has become very conservative starting with OneUI 8.x.

I am not sure if this symptom appears on devices from other manufacturers, but since it is currently occurring on all Samsung OneUI 8.x devices, there is a significant performance drop when using an X server via Termux-X11 or x11vnc. Therefore, I believe a review of improvement directions is necessary!

Thank you!