L4T 21.4 Jetson - Maximizing CPU performance in rc.local - scaling_governor is not setting

following the recommendation, i’ve placed the commands from the wiki into /etc/rc.local

checking the system after reboot shows the the scaling governor is not set to “performance”.

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
interactive

after the system comes up, i can set this manually. any clues about setting this automatically, is my system broken, other ideas?

i see similar behavior with maximizing the GPU settings via rc.local.

thanks for any feedback or assistance!

reference:

http://elinux.org/Jetson/Performance

my rc.local looks like this:

#!/bin/sh -e

mount /dev/sda15 /media/j/ss15

### Disable USB auto-suspend
echo -1 > /sys/module/usbcore/parameters/autosuspend

### Maximize CPU performance
echo 0 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable
echo 1 > /sys/devices/system/cpu/cpu0/online
echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

### GPU performance
echo 852000000 > /sys/kernel/debug/clock/override.gbus/rate
echo 1 > /sys/kernel/debug/clock/override.gbus/state

### GPU memory clock
echo 924000000 > /sys/kernel/debug/clock/override.emc/rate
echo 1 > /sys/kernel/debug/clock/override.emc/state

exit 0

I suspect that sometimes the order of setting parameters may get in the way. If you comment out everything in that script and run the commands by hand in exactly that order does anything fail or change?

Try removing the -e from the first line. That causes the script to exit immediately on a first error. I think that e.g. trying to put a core online with the echo command returns an error if it’s already online.

thanks, that helped, made it further. (edit: this post is response to linuxdev.)

i did get an error from manually setting cpu0 online. i removed all four of those lines, they don’t seem to make a helpful difference. something else is forcing them all online.

even after successfully setting the scaling_governor, it is falling back to “interactive” anyway. however, the CPU frequency is staying maximized.

at this point i have one command to run manually, which is the last one, line 20 below.

swapping the order of lines 19 & 20 made no difference. calling a bash script (without -e flag) for those two lines made no difference. i had used echo commands directed to a log file so as to find how far rc.local made it.

currently the error log shows

sh: echo: I/O error

this is the rc.local file

#!/bin/sh -e
exec 2> /tmp/rclocal.log
exec 1>&2

mount /dev/sda15 /media/j/ss15

### Disable USB auto-suspend
echo -1 > /sys/module/usbcore/parameters/autosuspend

### Maximize CPU performance
echo 0 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

### Maximize GPU memory clock
echo 924000000 > /sys/kernel/debug/clock/override.emc/rate
echo 1 > /sys/kernel/debug/clock/override.emc/state

### Maximize GPU performance
echo 852000000 > /sys/kernel/debug/clock/override.gbus/rate
echo 1 > /sys/kernel/debug/clock/override.gbus/state

exit 0

yes, that is what i got.

i just now removed the -e and get no difference. the GPU clock override is still 0. (referring to line 20 in my rc.local in post #4)

duplicate

As mentioned by kulve, you will get errors when you try to set some items to a state they are already in, e.g., cpu0 when you are poking around in a shell will always be online, also during boot; trying to set it online when it is already online returns an error. The acid test for results is actually testing online status before and after the script is complete.

I have not experimented with clock rates, but I’ve seen various people comment that there are often restrictions on various clock rates which might change depending on other setup…the available rates can be a moving target. On my system, I tried echo of “performance” to scaling_governor, and it stayed where it should be. However, if you look at the Jetson performance article on eLinux.org, you’ll see that manually setting a clock rate requires “userspace”, not “performance”. It seems logical that when the governor and clocks are told something incompatible, e.g., performance mode with a clock being overridden, that one of those two parameters will have to be forcibly set by the system to something other than what was requested.

In general terms of I/O errors, some parameters are read-only or write-only and may be the cause. Trying to set a cpu to online when it is already online might cause this when run from a script.

i found i don’t need to set cpu online in that the tegra_cpuquiet setting is doing that job behind the scenes. i get all four online with that. as well, the “G”, the general cluster is active.

i have tried the “userspace” setting, it’s in my rc.local now.

it has not changed the result with GPU clock override, i.e. i still have to manually set the state. both those lines still produce errors when run from rc.local. the two files are writable by root (file mode 644).

in this configuration, scaling_governor still falls back to “interactive” and cpuinfo_cur_freq will move around and definitely hit the max setting with sufficient load on the system.

overall it seems i’m getting the exact same result whether i set scaling for performance or userspace. my “load test” of doing a video conversion completes in about the same time. this is after manually setting the GPU clock override in all cases.

i would still like to get the final piece done properly.

this is my current rc.local.

#!/bin/sh
exec 2> /tmp/rclocal.log
exec 1>&2

mount /dev/sda15 /media/j/ss15

### Disable USB auto-suspend
echo -1 > /sys/module/usbcore/parameters/autosuspend

### Maximize CPU performance
echo 0 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable
echo "userspace" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 2320500 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

### Maximize GPU memory clock
echo 924000000 > /sys/kernel/debug/clock/override.emc/rate
echo 1 > /sys/kernel/debug/clock/override.emc/state

### Maximize GPU performance
echo 852000000 > /sys/kernel/debug/clock/override.gbus/rate
echo 1 > /sys/kernel/debug/clock/override.gbus/state

exit 0

thanks for the helpful comments thus far.

while looking into adding another rc script to run the GPU clock override command, i noticed
/etc/rc2.d/S99ondemand

disabling that script has stopped my system from falling back to “interactive” that i mentioned above.

similarly to ondemand, i made a fixGPUclock script with a sleep delay to set the GPU clock override.

this is working, i don’t have to manually set this parameter.