Horrible performance on battery with intel_pstate driver

Question

EDIT: Ubuntu (mate) 20.04, intel_pstate driver. Computer is I am using a razer blade stealth ultrabook (early 2019), with intel core i7 i7-8565U.

I am encountering odd behavior (extreme slowdown) while on battery power only, even when I have set TLP to AC mode. The problem is made much worse if I set cpufrequtils to performance mode (espeically if I multithread)!

We'll start with the single threaded case (i.e. only main thread). I am running a cascade of OPENCV filters (Gaussian blurs etc.) on video frames from file or from webcam. It does not matter if I load all the frames into memory first (i.e. it's not disk or device I/O problem). Below are listed the processing time for a single loop (one frame). This is not complex code. Basically, it is doing:

Filter filters[400]
while( cap.read(frame) )
{
 for( int i=0; i<400; ++i )
 {
  filters[i].dofilter(frame);
 }
}

where filters[i].dofilter is just call to e.g. cv::GaussianBlur, resize(), etc, with the destination cv::Mat pre-allocated (I am not doing any additional allocations)

This is using CPU only (i.e. it's not using OPENCV transparent openCL or anything).

SINGLE THREAD

AC  + powersave:    71 msec (variance 70.5-71.5)
AC  + performance:  67 msec (variance 66.5-67.5)
BAT + powersave:    95 msec (variance 84.0-115.0)  *1
BAT + performance:  104 msec (variance 76.0-202.0) *2

1* Note: spikes to 110+ about every 5 sec
2* Note:  most ~96, with few spikes low to 80s and high to 120s

Method: 10 runs of each condition for 60 seconds (about 600 frames each times 10 runs = 6000), randomly ordered (so that heat, battery voltage, etc. does not confound).

I use the same input frame for every loop (in other words, it is not due to different image content that it is processing each time). It is literally processing the exact same input every time step. I can see the per-frame processing times change immediately if I unplug or plug in the AC adapter or set powersave/performance using cpufrequtils.

I am at a complete loss.

I am using a razer blade stealth ultrabook, with intel core i7 i7-8565U. Ubuntu (mate) 20.04, intel_pstate driver.

So, I have 3 specific questions:

1) What the hell is happening?

2) How to set TLP (kernel params?) to force it to behave as if on AC (surely the battery can provide enough to run a cpu/memory bound single-core program as fast as it does when on AC)? It's not even doing that much!

3) Is there any secret/weird settings that happen on battery power. Especially relating to multithreading? The problem is highly parallelizable -- there are basically 8 independent chains of filters that I can run in parallel. Usually I do this. When I do this on AC it goes like this:

MULTITHREAD (8 threads)

AC  + powersave:    28.6 msec (variance 26.8-31.1)
AC  + performance:  28.8 msec (variance 26.6-31.2)
BAT + powersave:    39 msec (variance 36.0-64.0)   *3
BAT + performance:  176 msec (variance 39.0-202.0) *4

3* Note: this is very tame compared to if I run with webcam -- then it spikes heavily between 40 and 90

4* Note: will update at 40 msec for a few frames, then go to 180 msec for a long time, then burst at 40 for a few.

The software is multithreaded via a thread pool. I have checked the locking, and no time is spent waiting for locks even in the extreme multithreaded case (this is actually where I spent the most time because I thought it was the issue originally...). I get similar results with 2~8 threads. Gets slower on battery with more threads (especially in performance mode), and faster on AC with more threads.

EDIT: problem happens even if I disable TLP. I have not tried switching to old acpi frequency governer yet (think that would work?)

EDIT 2: When in single thread mode, htop shows only a single CPU core pegged (i.e. it is not using openmp or something to vectorize and use more cores).

Answer 1

The issue was the intel_pstate driver.

I switched to the original ACPI driver via boot kernel parameters. Specifically, in /etc/default/grub, I changed the DEFAULT boot line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=disable acpi=force"

(remember to update-grub after).

Now, even with no changes at all (i.e. default "ondemand"):

MULTITHREAD (8 threads)

BAT + ondemand:     38.5 (37.5 ~ 40.0)
BAT + performance:  31.8 (30.1 ~ 35.0) *1

1* I see some very small spikes to 35 once every few seconds, but it is within reason...

Ironically, power consumption during normal workload (browsing, EMACS, on wifi etc.) actually also got BETTER using ACPI driver than intel_pstate (average 590 mA vs 660 mA). A happy (but worrisome) side effect.

EDIT: one downside is that it seems that suspend (sleep mode) consumes more power when not using the intel_pstate driver. About 10% every 12 hours...

Answer 2

Here are my kernel make "DESCEND only"-benchmarks (ie. just make when there is nothing to do - a couple of seconds).

It took me some time before I realised the -j option in make; and that I do not have to reboot to change the Turbo-Boost and SMT/Hyperthreading settings: they can be accessed via /sys.

My TDP is 28W. It is not a laptop, but also i5-8259U. It normally (like right now) consumes 3.5W-5W. Here are some of the results I noted, with focus on the Watts I physically mesured.

time make -j10 -O O=../make-out/

TB+HT,mitigations=off

-j8:    4.8s    57W (max.)
-j4:   12.3s    20W (-35W)  
no-j:  21.7s    19W (max.)
-j4II:  6.4s    45W

It would be more precise in Joule instead. I think the 57W include the fan. The two -j4 results show: the total energy (Ws=Joule) stays more or less constant.

TB no, HT yes
-j10:  7.7s  22W

And the last test I noted down:

TB 25-35-1sec "tau", HT yes, mitig.=off
-j10:  5.2s  40W

This Turbo-Boost setting was from the BIOS - it seemed to help to limit the "57W max." from the first run.

But with 75 (percent) written to intel_pstate/max_perf_pct in sysfs I found now a better way to have a boost, but only to 3.0GHz instead of 3.8GHz.

Now I get it in 5.5s with 35W (max. 44W), compared to 4.8s at 50W or so. No Boost is 6.7s at 25W.

---

More active cores and higher CPU frequency can make a huge differnce in time and watts. The GPU can even add to that (in your exampl?), and the fan.

I don't now if the battery has a problem with too much amperes, besides getting empty (very) soon. But my measurements show that the difference can be huge, and some throttling might kick in - normally it is the temperature.

But with a razor blade ultrabook - poor battery!