> Date: Sun, 20 Mar 2022 18:13:16 +0100
> From: Solene Rapenne <[email protected]>
>
> I'm proposing a very simple change to the automatic policy of the CPU
> frequency scheduler.
>
> Currently, every 100ms the scheduler is doing this:
>
> - when the CPU load exceeds the threshold, CPU frequency is set to the
> maximum and the variable downbeats is set to 5.
> - when the CPU load is below the threshold, downbeats is decremented, if
> it's == 0 then the CPU load is reduced to 0
>
> my proposal is to change the downbeat to be adaptive to the load, instead
> of setting it to 5 all the time, I propose to increment it with a limit
> of 5. Instead of having the frequency set at max for 500ms (5 cycles)
> every time the CPU usage is above the treshold, we will keep the
> frequency high for a number of cycles depending how long it was high
> (up to 5). So, in case of short CPU usage burst like opening a new MP3
> file for decoding or a click on a GUI, we have a frequency burst of
> 100ms instead of 500ms.
>
> I've been using it for a few days, I noticed a huge battery life
> improvement with no responsiveness change.
I've been using variants of this diff on several machines now, and I
think it is an imrpovement and should go in.
I'm still experimenting with diffs that bring back cpu frequency
scaling on machines that are not running on battery and what I have
builds on top of this diff.
So, ok kettenis@
> Index: sched_bsd.c
> ===================================================================
> RCS file: /home/reposync/src/sys/kern/sched_bsd.c,v
> retrieving revision 1.70
> diff -u -r1.70 sched_bsd.c
> --- sched_bsd.c 30 Oct 2021 23:24:48 -0000 1.70
> +++ sched_bsd.c 20 Mar 2022 16:30:22 -0000
> @@ -579,8 +579,8 @@
> }
> if (allidle < alltotal / 2)
> speedup = 1;
> - if (speedup)
> - downbeats = 5;
> + if (speedup && downbeats < 5)
> + downbeats++;
>
> if (speedup && perflevel != 100) {
> faster:
>
>
