Revision history [back]

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesyste. Though if reboot didn't happened, system seems stable afterwards. I'm going to leave cpu in the fast mode, and see how it goes.

    #!/bin/bash

    GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

    function switch_cores {
            state="$1"
            shift

            for c in "$@"; do
                    fname=/sys/devices/system/cpu/cpu$c/online
                    if [ "$(cat $fname)" != "$state" ]; then
                            echo $state >$fname
                    fi
            done
    }


    case "$1" in
    "fast")
            echo userspace >$GOVERNOR
            switch_cores 1  4 5
            switch_cores 0  0 1 2 3
            ;;
    "slow")
            echo userspace >$GOVERNOR
            switch_cores 1  0 1 2 3
            switch_cores 0  4 5
            ;;
    "all")
            echo userspace >$GOVERNOR
            switch_cores 1  0 1 2 3 4 5
            ;;
    "default")
            echo rqbalance >$GOVERNOR
            ;;
    *)
            echo "Usage: $0 [fast|slow|all|default]"
            exit -1
            ;;
    esac


    echo "governor:" $(cat $GOVERNOR)
    for c in 0 1 2 3 4 5; do
            echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
    done

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesyste. Though if reboot didn't happened, system seems stable afterwards. I'm going to leave cpu in the fast mode, and see how it goes.

 #!/bin/bash

 GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

 function switch_cores {
         state="$1"
         shift

         for c in "$@"; do
                 fname=/sys/devices/system/cpu/cpu$c/online
                 if [ "$(cat $fname)" != "$state" ]; then
                         echo $state >$fname
                 fi
         done
 }


 case "$1" in
 "fast")
         echo userspace >$GOVERNOR
         switch_cores 1  4 5
         switch_cores 0  0 1 2 3
         ;;
 "slow")
         echo userspace >$GOVERNOR
         switch_cores 1  0 1 2 3
         switch_cores 0  4 5
         ;;
 "all")
         echo userspace >$GOVERNOR
         switch_cores 1  0 1 2 3 4 5
         ;;
 "default")
         echo rqbalance >$GOVERNOR
         ;;
 *)
         echo "Usage: $0 [fast|slow|all|default]"
         exit -1
         ;;
 esac


 echo "governor:" $(cat $GOVERNOR)
 for c in 0 1 2 3 4 5; do
         echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
 done

TLDR: TLDR: unconditionally enable fast cores to get 40% decrease in app load times and 1.7x speedup in exchange for battery life. Also see warning below.

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesyste. Though if reboot didn't happened, system seems stable afterwards. I'm going to leave cpu in the fast mode, and see how it goes.

#!/bin/bash

GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

function switch_cores {
        state="$1"
        shift

        for c in "$@"; do
                fname=/sys/devices/system/cpu/cpu$c/online
                if [ "$(cat $fname)" != "$state" ]; then
                        echo $state >$fname
                fi
        done
}


case "$1" in
"fast")
        echo userspace >$GOVERNOR
        switch_cores 1  4 5
        switch_cores 0  0 1 2 3
        ;;
"slow")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3
        switch_cores 0  4 5
        ;;
"all")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3 4 5
        ;;
"default")
        echo rqbalance >$GOVERNOR
        ;;
*)
        echo "Usage: $0 [fast|slow|all|default]"
        exit -1
        ;;
esac


echo "governor:" $(cat $GOVERNOR)
for c in 0 1 2 3 4 5; do
        echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
done

Edit: code formatting & TLDR

TLDR: unconditionally enable fast cores to get 40% decrease in app load times and 1.7x speedup in exchange for battery life. Also see warning below.

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesyste. Though if reboot didn't happened, system seems stable afterwards. I'm going to leave cpu in the fast mode, and see how it goes.

#!/bin/bash

GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

function switch_cores {
        state="$1"
        shift

        for c in "$@"; do
                fname=/sys/devices/system/cpu/cpu$c/online
                if [ "$(cat $fname)" != "$state" ]; then
                        echo $state >$fname
                fi
        done
}


case "$1" in
"fast")
        echo userspace >$GOVERNOR
        switch_cores 1  4 5
        switch_cores 0  0 1 2 3
        ;;
"slow")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3
        switch_cores 0  4 5
        ;;
"all")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3 4 5
        ;;
"default")
        echo rqbalance >$GOVERNOR
        ;;
*)
        echo "Usage: $0 [fast|slow|all|default]"
        exit -1
        ;;
esac


echo "governor:" $(cat $GOVERNOR)
for c in 0 1 2 3 4 5; do
        echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
done

Edit: code formatting & TLDRTLDR & fix title

TLDR: unconditionally enable fast cores to get 40% decrease in app load times and 1.7x speedup in exchange for battery life. Also see warning below.

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesyste. filesystem. Though if reboot didn't happened, happen, system seems stable afterwards. I'm going to leave cpu of my phone in the fast mode, and see how it goes.

#!/bin/bash

GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

function switch_cores {
        state="$1"
        shift

        for c in "$@"; do
                fname=/sys/devices/system/cpu/cpu$c/online
                if [ "$(cat $fname)" != "$state" ]; then
                        echo $state >$fname
                fi
        done
}


case "$1" in
"fast")
        echo userspace >$GOVERNOR
        switch_cores 1  4 5
        switch_cores 0  0 1 2 3
        ;;
"slow")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3
        switch_cores 0  4 5
        ;;
"all")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3 4 5
        ;;
"default")
        echo rqbalance >$GOVERNOR
        ;;
*)
        echo "Usage: $0 [fast|slow|all|default]"
        exit -1
        ;;
esac


echo "governor:" $(cat $GOVERNOR)
for c in 0 1 2 3 4 5; do
        echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
done

Edit: code formatting & TLDR & fix titletitle & fix grammar

TLDR: unconditionally enable fast cores to get 40% decrease in app load times and 1.7x speedup in exchange for battery life. Also see warning below.

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesystem. Though if reboot didn't happen, system seems stable afterwards. I'm going to leave cpu of my phone in the fast mode, and see how it goes.

#!/bin/bash

GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

function switch_cores {
        state="$1"
        shift

        for c in "$@"; do
                fname=/sys/devices/system/cpu/cpu$c/online
                if [ "$(cat $fname)" != "$state" ]; then
                        echo $state >$fname
                fi
        done
}


case "$1" in
"fast")
        echo userspace >$GOVERNOR
        switch_cores 1  4 5
        switch_cores 0  0 1 2 3
        ;;
"slow")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3
        switch_cores 0  4 5
        ;;
"all")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3 4 5
        ;;
"default")
        echo rqbalance >$GOVERNOR
        ;;
*)
        echo "Usage: $0 [fast|slow|all|default]"
        exit -1
        ;;
esac


echo "governor:" $(cat $GOVERNOR)
for c in 0 1 2 3 4 5; do
        echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
done

Edit: code formatting & TLDR & fix title & fix grammar

TLDR: unconditionally enable fast cores to get 40% decrease in app load times and 1.7x speedup in exchange for battery life. Also see warning below.

Xperia's MSM8956 CPU has 2 fast A72 cores and 4 slower low-power A53 cores. Default kernel scheduler powers up faster cores only if all 4 slower cores are loaded with work, and it's very rare occurence to load 4 cores on a phone, so A72s usually stay disabled. It's a known problem, and I think here on TJC sailors said that they won't do ad-hoc fixes and will wait for newer 4.x kernel integration into Sailfish. It's supposed to have better scheduling policies and to solve this problem without extra work from Jolla.

I happened to run a small computational problem yesterday, and noticed that faster cores are actually 2-3x faster. This potential shouldn't be wasted! Well, raw computational power doesn't translate 1:1 to faster load times. So I did a small benchmark with firefox for android and measured time it takes from tap on screen to fully loaded browser with homepage tab opened (meaning it's loaded, screen finished updating; tab doesn't load any site and shouldn't do network access). To time it, I recorded the process on my PC's webcam and counted frames afterwards. On slower cores it takes 83 frames, on faster cores 48 frames at 30fps (2.7s vs 1.6s). So it's 1 second faster, 1.7x more performance, 40% load time reduction. This benchmark is far from robust, but I guess it shows potential and what to expect.

Below is the script to set scheduler into manual mode. Use sudo ./cpu.sh fast to enable only fast cores and disable slow ones. Set param to all to enable all, slow to leave only slow cores running, and default to revert to the initial state. First save the script somewhere as cpu.sh, run chmod 755 cpu.sh to make it executable.

Warning: Use at your own risk! Turning on fast cores will reduce battery time, I haven't measured the effect yet. Occasionally running the script causes immidiate reboot, and unexpected reboots can damage filesystem. Though if reboot didn't happen, system seems stable afterwards. I'm going to leave cpu of my phone in the fast mode, and see how it goes.

#!/bin/bash

GOVERNOR=/sys/devices/system/cpu/cpuquiet/current_governor

function switch_cores {
        state="$1"
        shift

        for c in "$@"; do
                fname=/sys/devices/system/cpu/cpu$c/online
                if [ "$(cat $fname)" != "$state" ]; then
                        echo $state >$fname
                fi
        done
}


case "$1" in
"fast")
        echo userspace >$GOVERNOR
        switch_cores 1  4 5
        switch_cores 0  0 1 2 3
        ;;
"slow")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3
        switch_cores 0  4 5
        ;;
"all")
        echo userspace >$GOVERNOR
        switch_cores 1  0 1 2 3 4 5
        ;;
"default")
        echo rqbalance >$GOVERNOR
        ;;
*)
        echo "Usage: $0 [fast|slow|all|default]"
        exit -1
        ;;
esac


echo "governor:" $(cat $GOVERNOR)
for c in 0 1 2 3 4 5; do
        echo "core $c:"  $(cat /sys/devices/system/cpu/cpu$c/online)
done

Edit: code formatting & TLDR & fix title & fix grammar