4

I have a laptop with an Intel i7-1065G7 cpu. turbostat reports

35 * 100.0 = 3500.0 MHz max turbo 8 active cores
35 * 100.0 = 3500.0 MHz max turbo 7 active cores
35 * 100.0 = 3500.0 MHz max turbo 6 active cores
35 * 100.0 = 3500.0 MHz max turbo 5 active cores
35 * 100.0 = 3500.0 MHz max turbo 4 active cores
35 * 100.0 = 3500.0 MHz max turbo 3 active cores
38 * 100.0 = 3800.0 MHz max turbo 2 active cores
39 * 100.0 = 3900.0 MHz max turbo 1 active cores

(these are 4 physical/8 virtual cores) When I throw a large single-thread load (calculating pi with mpfr) at the cpu I observe that two cores (maybe one physical core?) run at exactly 3500 MHz while the others have a lower frequency. But they never reach the higher turbo boost frequencies.

If I disable some of the cpu cores (e.g. with echo 0 > /sys/devices/system/cpu/cpu[2-7]*/online) the laptop does reach the corresponding higher turbo boost frequencies, resulting in increased performance (a task that took on average 18.5 seconds before now takes 16.8).

How can I get my new laptop to reach its maximal clock speed when not all cores are needed?

I'm using Ubuntu 20.04 with kernel 5.4.0 on an HP Envy x360 laptop.

What I expect: On my old laptop with an i7-4712MQ turbostat gives

30 * 100.0 = 3000.0 MHz max turbo 4 active cores
30 * 100.0 = 3000.0 MHz max turbo 3 active cores
32 * 100.0 = 3200.0 MHz max turbo 2 active cores
33 * 100.0 = 3300.0 MHz max turbo 1 active cores

(this is also a 4/8 core machine). On this machine a single-core load makes one core boost to almost 3.3 GHz, under a two-core load two clock at 3.2 GHz etc.

I haven't checked individual cpu frequencies on Windows, but the task manager sometimes displays frequencies above 3.7GHz.

Update: So the problem disappeared... I have no idea why. I did uninstall linux-cloud-tools but I don't think this should be the reason.

0x539
  • 267
  • 4
  • 18
  • It seems likely that you have enough other stuff going on that other cores are active enough to prevent your computer getting to 3.8 or 3.9 GHz. I do not know of a workaround for computers running a GUI. I am a server person, with no GUI, and if I turn off unneeded services, I can get my max 1 core limit easily. Your question is stated clearly and completely, thanks, You could try forcing CPU affinity for your single thread task, so as to avoid CPU switching, with related ramp up times. – Doug Smythies Aug 17 '20 at 21:11
  • @DougSmythies I don't think so. If I disable 6 cores and run a single threaded task (calculating pi with mpfr) I get less than 60% total usage and the task does finish faster. – 0x539 Aug 17 '20 at 21:15
  • Can you confirm your exact CPU, I can't find it on [intel ark](https://ark.intel.com/content/www/us/en/ark.html) – Philip Couling Aug 17 '20 at 21:52
  • Ah, I mistyped it. It's the [i7-1065G7](https://ark.intel.com/content/www/us/en/ark/products/196597/intel-core-i7-1065g7-processor-8m-cache-up-to-3-90-ghz.html). – 0x539 Aug 17 '20 at 22:04
  • Oh, then you might need the performance governor instead of the default powersave governor. I would still suggest to force CPU affinity for the single thread. – Doug Smythies Aug 17 '20 at 22:50
  • @DougSmythies Good idea, I hadn't checked that. Sadly it still doesn't boost over 3.5GHz. – 0x539 Aug 17 '20 at 22:55
  • Your old computer does not have HWP (HardWare Pstate) control, your new one does. Try disabling HWP via intel_pstate=no_hwp on the grub command line. – Doug Smythies Aug 17 '20 at 23:00
  • @DougSmythies sadly that does not seem to make any difference – 0x539 Aug 18 '20 at 00:58
  • did you try forced CPU affinity? i.e. taskset -c 5 single-threaded-command? – Doug Smythies Aug 18 '20 at 13:56
  • @DougSmythies for the record, that did not help either. – 0x539 Aug 21 '20 at 14:14
  • Then I return to my first comment, and assert that it is what is happening. Your test of disabling cores merely forces those other tasks onto the remaining cores. – Doug Smythies Aug 21 '20 at 14:34

2 Answers2

0

You wrote...

When I throw a large single-thread load

If your program is single threaded it doesn't need to go to the maximum frequency on the other threads so it doesn't.

Your link is for the Intel® Core™ i7-1065G7 Processor.

The Intel document you linked says the max is 3900 MHz. Your data seem to show there is a core at 3900 MHz so I don't know why you think it did not hit the maximum. You posted this...

35 * 100.0 = 3500.0 MHz max turbo 8 active cores
35 * 100.0 = 3500.0 MHz max turbo 7 active cores
35 * 100.0 = 3500.0 MHz max turbo 6 active cores
35 * 100.0 = 3500.0 MHz max turbo 5 active cores
35 * 100.0 = 3500.0 MHz max turbo 4 active cores
35 * 100.0 = 3500.0 MHz max turbo 3 active cores
38 * 100.0 = 3800.0 MHz max turbo 2 active cores
39 * 100.0 = 3900.0 MHz max turbo 1 active cores

In general if the reading is not the maximum frequency it's because either it does so only intermittently so the measurement will only show that intermittently or else it doesn't need to be at the maximum frequency because there is some constraint such as IO. Don't worry about it. If you write a program that has no constraints, in other words, it is a compute constrained thread, I guarantee it will go to the max frequency.

An elapsed time of 18.5 s may not be meaningful because of random effects that you don't want to use to draw conclusions. Long running jobs of 200 seconds or more might give you more meaningful data.

H2ONaCl
  • 9,513
  • 28
  • 73
  • 109
  • Exactly, but I would like the core it is being executed on to boost to 3.9 GHz – 0x539 Aug 18 '20 at 01:02
  • Okay I will delete the information that does not interest you. – H2ONaCl Aug 18 '20 at 01:06
  • This still doesn't address the issue. I don't care about the other cores, just about the one the program runs on. – 0x539 Aug 18 '20 at 01:07
  • I addressed the issue where I said there is a constraint. – H2ONaCl Aug 18 '20 at 01:16
  • I updated my question to make clear that disabling cores results in higher frequencies and a measurable increase in performance for a computation-constrained task. – 0x539 Aug 18 '20 at 01:18
  • As I wrote the cpu cores do not go over 3.5GHz (according to `/sys/devices/system/cpu/cpu$i/cpufreq/scaling_cur_freq`). The data I posted is simply `turbostat`'s reporting of processor specs, not the actual frequency of the cpu. – 0x539 Aug 18 '20 at 01:22
  • Those are not specs. It says scaling_cur_freq . That means it is the current frequency. – H2ONaCl Aug 18 '20 at 01:25
  • What you cite is **not** a frequency reading, but the output of `turbostat` which gives (static) system information. – 0x539 Aug 18 '20 at 21:08
0

I experienced something similar, on a similar setup (i7-9700K CPU, Ubuntu 18.04). And I think my machine usage may be similar: it's a desktop machine that I use for running some intensive (but single-thread) applications, while also possibly having a web browser and some messaging apps open. I found the suggestion in the comments under the original post to work - setting the CPU affinity for processes. I used taskset to do it [1].

First test (no changes to affinity settings): All 8 cores 'idling' at ~10% utilisation. I start a single threaded, CPU intensive task. One core jumps to 100%, I see 3.6 GHz (the max without turbo) on all cores using i7z.

Second test: Restrict all running processes to CPU cores 0 & 1, with: for i in `sudo ps -aux | awk '{ print $2 }'`; do sudo taskset -a -p -c 0-1 $i; done. Now those 2 cores sit at 30-40%, the rest at 0% (although some other cores may start to get activity as the OS starts processes). Then start the same single threaded, CPU intensive task. One core jumps to 100%, but now I see it reach the max turbo frequency of 4.9 GHz. Afterwards I set the affinity back to use all cores by replacing the 0-1 range with 0-7, in my case.

[1] http://manpages.ubuntu.com/manpages/focal/man1/taskset.1.html

thesps
  • 1
  • 1
  • 1
    *"setting the CPU affinity for processes"*- this is the **only** part of this answer that actually moves to answer the question and it's not clear. The rest of the answer is narrative explaining that you had the same problem and how you don't have the problem anymore. Our [Q&A format](https://askubuntu.com/tour) is all about getting answers and reducing chit chat and distraction. It's fine to go into additional details if they help explain the answer, but you should expand on **how** to apply your solution- make sure that it stands clearly apart from anything not needed to convey the solution. – Nmath Sep 28 '20 at 14:53