Re: [patch] CPU frequency scheduler change proposal
> Date: Sun, 20 Mar 2022 18:13:16 +0100
> From: Solene Rapenne
>
> 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 - 1.70
> +++ sched_bsd.c 20 Mar 2022 16:30:22 -
> @@ -579,8 +579,8 @@
> }
> if (allidle < alltotal / 2)
> speedup = 1;
> - if (speedup)
> - downbeats = 5;
> + if (speedup && downbeats < 5)
> + downbeats++;
>
> if (speedup && perflevel != 100) {
> faster:
>
>
Re: [patch] CPU frequency scheduler change proposal
Am Mon, 21 Mar 2022 16:31:42 +0100 schrieb Matthias Schmidt : > Hi, > > * Solene Rapenne wrote: > > 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 have the patch running since the weekend (when it was first shared) > and noticed that my CPU on battery spins up less often than before. I > have the feeling that my battery lasts longer, however, I need to do > some more measurements to have a proof. I've tried the patch and can confirm this on my old netbook. The fan spins considerably less often, the system feels a bit more responsive and the battery seems to last longer. At this point in time I cannot tell how much longer the battery lasts exactly, but even quieter fan alone makes the patch worthwile for me. Thank you Solene! -- greetings, Florian Viehweger
Re: [patch] CPU frequency scheduler change proposal
On 2022/03/20 19:51, Stuart Henderson wrote: > On 2022/03/20 18:13, Stuart Henderson wrote: > > On 2022/03/20 18:13, Solene Rapenne wrote: > > > 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. > > Running with this now btw (on AC power, but I have #ifdef'd out the > relevant parts of kern/sched_bsd.c). Watching with 'iwatch -i0.05 apm' > it seems to be reacting nicely to changes in use, for example a very > short blip at full speed when opening a new term and it drops down > again quickly. And stays at high cpu during compiles as I'd expect. > Also importantly, it stays at low speed with a browser with various > tabs running, during which time there is some cpu load but not a high > demand. > > > > > I've been using it for a few days, I noticed a huge battery life > > ^ > > > improvement with no responsiveness change. > > ^^^ > > > > This (and the couple of complaints from people who have now seen the fan > > stay on when plugged in, when it didn't previously) suggests that mwait > > is not everything and it _would_ still make sense to still have a way to > > set automatic frequency rather than just force-high for plugged-in use > > too... > > Just remembered I've got a shelly 1pm coming next week for something else, > before I do that I can bodge a cable to plug my laptop in through it and > get some figures that I'm hoping should be a bit more useful than the > instantaneous readings from my UPS. > > (As of next month's prices here, 10W continuous will be approx GBP30/year, > I've been trying to drop my base load as much as I can, everything helps!) > Some results from this. Firefox with ~75 tabs mostly idling, chromium 1 tab idling, vlc playing a network radio stream, and a bunch of terminals, on an X1Y4 i7-8565U (dmesg below) 17.5-25Wapm -H 13.4-15.7W apm -A (kernel patched to allow auto on AC, and using Solene's diff to adjust the CPU freq scheduler) 13.5W apm -L I was also interested in how things looked with a busier CPU; with a loop of md5 -t (single instance not multiple in parallel, I wanted to give as much chance of allowing turbo to kick in as possible on -H) looking at times and power: apm -L, steady 14.7W around 0.74sec apm -A or -H, starts around 35W 0.21sec but after a few seconds throttles 29W then 22W around 0.27sec. OpenBSD 7.1-beta (GENERIC.MP) #10: Sun Mar 20 19:24:32 GMT 2022 st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 16926281728 (16142MB) avail mem = 16396013568 (15636MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x77d49000 (64 entries) bios0: vendor LENOVO version "N2HET63W (1.46 )" date 06/01/2021 bios0: LENOVO 20QF00B2UK acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr:
Re: [patch] CPU frequency scheduler change proposal
Hi, * Solene Rapenne wrote: > 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 have the patch running since the weekend (when it was first shared) and noticed that my CPU on battery spins up less often than before. I have the feeling that my battery lasts longer, however, I need to do some more measurements to have a proof. Cheers Matthias
Re: [patch] CPU frequency scheduler change proposal
On 2022/03/20 18:13, Stuart Henderson wrote: > On 2022/03/20 18:13, Solene Rapenne wrote: > > 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. Running with this now btw (on AC power, but I have #ifdef'd out the relevant parts of kern/sched_bsd.c). Watching with 'iwatch -i0.05 apm' it seems to be reacting nicely to changes in use, for example a very short blip at full speed when opening a new term and it drops down again quickly. And stays at high cpu during compiles as I'd expect. Also importantly, it stays at low speed with a browser with various tabs running, during which time there is some cpu load but not a high demand. > > I've been using it for a few days, I noticed a huge battery life > ^ > > improvement with no responsiveness change. > ^^^ > > This (and the couple of complaints from people who have now seen the fan > stay on when plugged in, when it didn't previously) suggests that mwait > is not everything and it _would_ still make sense to still have a way to > set automatic frequency rather than just force-high for plugged-in use > too... Just remembered I've got a shelly 1pm coming next week for something else, before I do that I can bodge a cable to plug my laptop in through it and get some figures that I'm hoping should be a bit more useful than the instantaneous readings from my UPS. (As of next month's prices here, 10W continuous will be approx GBP30/year, I've been trying to drop my base load as much as I can, everything helps!)
Re: [patch] CPU frequency scheduler change proposal
On 2022 Mar 20 (Sun) at 18:13:20 + (+), Stuart Henderson wrote:
:On 2022/03/20 18:13, Solene Rapenne wrote:
:> 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.
: ^^^
:
:This (and the couple of complaints from people who have now seen the fan
:stay on when plugged in, when it didn't previously) suggests that mwait
:is not everything and it _would_ still make sense to still have a way to
:set automatic frequency rather than just force-high for plugged-in use
:too...
:
In some unscientific tests, my laptop cpu cools down by 20c simply
between plugged in and on battery.
imho, it's time to ressurect Cool Mode.
:>
:> 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 - 1.70
:> +++ sched_bsd.c 20 Mar 2022 16:30:22 -
:> @@ -579,8 +579,8 @@
:> }
:> if (allidle < alltotal / 2)
:> speedup = 1;
:> -if (speedup)
:> -downbeats = 5;
:> +if (speedup && downbeats < 5)
:> +downbeats++;
:>
:> if (speedup && perflevel != 100) {
:> faster:
:>
:
--
It's illegal in Wilbur, Washington, to ride an ugly horse.
Re: [patch] CPU frequency scheduler change proposal
On 2022/03/20 18:13, Solene Rapenne wrote:
> 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.
^^^
This (and the couple of complaints from people who have now seen the fan
stay on when plugged in, when it didn't previously) suggests that mwait
is not everything and it _would_ still make sense to still have a way to
set automatic frequency rather than just force-high for plugged-in use
too...
>
> 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 - 1.70
> +++ sched_bsd.c 20 Mar 2022 16:30:22 -
> @@ -579,8 +579,8 @@
> }
> if (allidle < alltotal / 2)
> speedup = 1;
> - if (speedup)
> - downbeats = 5;
> + if (speedup && downbeats < 5)
> + downbeats++;
>
> if (speedup && perflevel != 100) {
> faster:
>
