That’s an interesting find. This “/etc/init.d/ondemand” file/service is installed as part of the initscripts package, and does not list actions for all of the /sys modes available to Jetson. This could easily get in the way of performance testing or setup without knowing it, as “performance” is summarily rejected by the script after a delay.
It looks like this part of initscripts has a means of detecting local login (perhaps GUI and/or console). I say this because the “ondemand” script has this line in it:
sleep 60 # probably enough time for desktop login
During my testing I had neither X11 login nor console login and was using ssh session only. My remote-only login could explain why performance mode never stopped for my tests, yet switched back to ondemand for you. There was never any “background” event for me since the local logins were non-existent and already “backgrounded” (why send a background event if already in background?).
I’m not completely sure of how init has this set up, but all of the modes known are taken from a /sys entry, so all possible modes are known to the script…yet the /etc/init.d/ondmand script switch case for “background” (presumably triggered by a service background or inactivity event) handles only these corner cases:
It seems that the initscript package maintainers (I haven’t looked for who that is) could modify the ondemand script to look for an optional config file as to what action to take on “background” event, rather than hard-coding for only three cases when the /sys content far exceeds those three cases. This would allow customizing for different hardware with different power saving options without modifying the initscripts package itself.