I have a fleet where I’ve updated the default device configuration with a variable am not seeing the update appear on the device. Is my understanding correct that device configuration variables prefixed with BALENA_HOST_CONFIG_are applied to the config.txt automatically (i.e. setting BALENA_HOST_CONFIG_isolcpus to 3 should add an entry into the config.txt with isolcpus=3)?
I am trying to set the isolcpus, trying both RESIN_HOST_CONFIG_isolcpus and BALENA_HOST_CONFIG_isolcpus. I’ve tried to reboot via the console and power cycling. The fleet has 3 devices, all are identical Raspberry Pi 5s running the latest Host OS (balenaOS 6.9.4+rev2). 1 device is in development mode, the other 2 are in production, but all are experiencing the same issue.
On the development device, if I manually update the /resin-boot/config.txt with the value, it works as expected.
Hi @bobbrez, and welcome to the forums!
Your understanding is correct: as per our documentation [1] any variable prefixed with BALENA_HOST_CONFIG_ added via the configuration tab on the dashboard will show up in config.txt. I just tested on a raspberry pi 4 device with BALENA_HOST_CONFIG_isolcpus and it works as expected.
Note that the change is visible in /mnt/boot/config.txt, whcih is the config file used by the OS, and not /resin-boot/config.txt which is a default file that is populated upon provisioning.
When you look at /mnt/boot/config.txt are you able to see the value isolcpus=3?
[1] Advanced boot settings | balena
Thank you for checking. The value in BALENA_HOST_CONFIG_isolcpus is making it into /mnt/boot/config.txt as expected. I was making an assumption that it would then in tern make it into the cmdline.txt as well, but it is not. Although the parameter it is getting set in the config.txt it does not actually affect the system unless it is present in cmdline.txt
A quick validation is running cat /sys/devices/system/cpu/isolated on the host to see if it is blank or the value from the param.
Is there any way to reliably update cmdline from the dashboard?
Unfortunately we don’t currently support changing cmdline.txt today, this is usually either done via a Custom Device support agreement or hacked by the user mounting the file and changing it from their container (which can be somewhat dangerous). We do have some plans to support this but it won’t happen with in 2026 unfortunately.
hello @bobbrez
You might consider using cpusets via your docker-compose.yml as a runtime alternative.
Docs: docker-compose.yml fields | balena docs
While this doesn’t offer 100% parity with the isolcpus kernel parameter (as the kernel may still occasionally use the cores for its own internal housekeeping or interrupts), it allows you to effectively partition your CPU resources at the application level.
From my understanding, isolcpus tells the kernel scheduler to ignore the cores entirely. cpuset simply tells the scheduler where it is allowed to put specific processes.
Implementation
To achieve an outcome similar to isolcpus, you essentially have to “carve out” the cores by restricting your other services. For example, if you want to isolate Core 3 for a specific high-performance task:
- Pin your critical service to Core 3.
- Explicitly restrict all other services to Cores 0-2.
services:
high-priority-task:
image: my-app/worker
# Isolates this service to the 4th core
cpuset_cpus: "3"
standard-service:
image: my-app/web
# Keeps this service off the 4th core
cpuset_cpus: "0,1,2"
I haven’t tried this personally, though.
Do let us know how it goes 