Individual core frequency switching

Bug #691721 reported by João Santos
124
This bug affects 23 people
Affects Status Importance Assigned to Milestone
indicator-cpufreq
Triaged
Low
Artem Popov

Bug Description

Indicator-cpufreq can't manage more than one core.

Artem Popov (artfwo)
Changed in indicator-cpufreq:
status: New → Triaged
assignee: nobody → Артём Попов (artfwo)
Artem Popov (artfwo)
Changed in indicator-cpufreq:
importance: Undecided → Low
Revision history for this message
seventhreign (seventhreign) wrote :

As requested by artfwo:

seventh@Seventh-Main ~ $ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 3.00 GHz
  available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 3.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 3.00 GHz:5.55%, 2.30 GHz:0.19%, 1.80 GHz:0.96%, 800 MHz:93.30% (1460557)
analyzing CPU 1:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 3.00 GHz
  available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 3.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 3.00 GHz:5.43%, 2.30 GHz:0.18%, 1.80 GHz:0.89%, 800 MHz:93.50% (1420590)
analyzing CPU 2:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 3.00 GHz
  available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 3.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 3.00 GHz:1.88%, 2.30 GHz:0.08%, 1.80 GHz:0.42%, 800 MHz:97.63% (1001754)
analyzing CPU 3:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 8.0 us.
  hardware limits: 800 MHz - 3.00 GHz
  available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 800 MHz and 3.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
  cpufreq stats: 3.00 GHz:1.47%, 2.30 GHz:0.04%, 1.80 GHz:0.25%, 800 MHz:98.24% (738690)
seventh@Seventh-Main ~ $

Revision history for this message
Artem Popov (artfwo) wrote :

Ah, I see. Your CPUs are independent from each other. I'm getting something like this on my laptop instead:
  CPUs which run at the same hardware frequency: 0 1

Possible GUI for handling several cores might be a preferences dialog, where affected CPUs will be selected by checkboxes.

Other possible proposal by Seventh Reign is here:
http://www.webupd8.org/2010/12/cpu-frequency-scaling-appindicator.html#comment-114330226

Core 1>
Core 2>
Core 3>
Core 4>

With the > being a submenu. Then in each of those 4 submenu's you'd have exactly what you have now. Thats just my idea tho. I'm sure there are other better ones.

What are your thoughts?

Revision history for this message
Stas Sușcov (sushkov) wrote :

Comment #2 looks reasonable to me.
Hope to see this soon in PPA.

Revision history for this message
Miloš Jovanović (mjovanovic) wrote :
Download full text (3.2 KiB)

I also have a similar problem - changing settings through the indicator on a dual core system only changes the freq of the first CPU.

Here's the output of my /cat/proc/cpuinfo if i change the indicator to 2Ghz (for example):

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
stepping : 6
cpu MHz : 2000.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips : 3990.34
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
stepping : 6
cpu MHz : 1000.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips : 3990.22
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

and here is the output of cpufreq-info:

driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz.
  cpufreq stats: 2.00 GHz:1.51%, 1.67 GHz:0.07%, 1.33 GHz:0.09%, 1000 MHz:98.33% (86493)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1000 MHz and 2.00 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz.
  cpufreq stats: 2.00 GHz:0.17%, 1.67 GHz:0.00%, 1.33 GHz:0.00%, 1000 MHz:99.83% (113)

It would be easier if the indicator could use one setting for both CPUs (perhaps of...

Read more...

Revision history for this message
seventhreign (seventhreign) wrote :

If it could or has to be done in a way that changing a single performance setting modifies all 1-6 cores at the same time, I think that would be acceptable. Changing each core individually would be a nice bonus, but how many people really do that?

Revision history for this message
Emre Senturk (m-emre-senturk) wrote :

following does the "change cpu scaling of all cores at the same time" thing. replace it with the one in /usr/local/lib/python2.6/dist-packages/indicator_cpufreq

Revision history for this message
Miloš Jovanović (mjovanovic) wrote :

I have to confirm that Emre's script works well on my Maverick 10.10 Thinkpad T60p - the indicator changes the frequency for all cores at the same time.

However, I had to put the script in /usr/lib/pymodules/python2.6/indicator_cpufreq

Revision history for this message
Jianlucah (gianlucavarrazzo) wrote :

Emre's script works fine, but only in /usr/lib/pymodules/python2.6/indicator_cpufreq.

If you have 2+ Cores you must change in line 37: FIXME_CPU = 2 in FIXME_CPU = "NUMBER OF CORES" (without quotes) to enable the other cores.

Revision history for this message
Nathanel Titane (nathanel.titane) wrote :

Can Emre integrate somekind of core number variable to fix FIXME_CPU = NUMBER OF CORES to reflect the physical number automatically?

Revision history for this message
Jianlucah (gianlucavarrazzo) wrote :

If you have Natty or Python 2.7, Emre's script must be put in /usr/lib/pymodules/python2.7/indicator_cpufreq (if you have another version of Python, script must be put in /usr/lib/pymodules/pythonxxx/indicator_cpufreq where xxx is the version of Python)

Revision history for this message
Karesz (lengyel-karesz) wrote :

Emre's script is working fine!
I made a little mockup for the indicator-cpufreq on multi cpu/core system in "Ondemand" mode (cores can run at different frequency).
I don't know, if anyone likes the idea.

description: updated
summary: - indicator-cpufreq only shows one CPU core
+ Only one core managing with indicator-cpufreq.
Revision history for this message
jul (jul) wrote : Re: Only one core managing with indicator-cpufreq.

Karesz, I like your modified indicator icon. What did you change?

Revision history for this message
Karesz (lengyel-karesz) wrote :

I haven't modified anything, it's only a mockup. It's made by gimp :)

Revision history for this message
István Kondor (kondor) wrote :

I like the mock-up and also the idea in comment #2. I hope it will be integrated soon.

Thanks in advance!

P.S.: I do change core speeds separately.

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

Hi everyone,

I'm attaching a proof of concept patch that I'm using which provides multicore support.
It's not ideal since it creates one indicator per cpu (you can set a limit with the new option --max-cpu n). Since I only have
two cores this is perfectly manageable (and that's how I used to do it with the old applet, just add as many applets
as cores).

If people are more interested I think I can implement idea in comment #2. That would give only one Indicator
(thus one icon), with a menu. The menu could be either flat:
CPU0
---------
Freq 1
Freq 2
...
---------
Governor 1
Governor 2
...
------------
CPU 1
...
------------
CPU 2

but this could become huge for say 4 or 8 cores, or I can just use submenus as in comment #2
Also the display icon (since there is only one) would use the frequency of the fastest running cpu.
(This would give the indication that one of your CPU is on full wack for instance).

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

Hi again,
actually implementing the submenu approach was quite easy, see the attached patch.

now the icon reflects the state of the highest frequency among all the cores.
As a bonus, the menu looks like this:

[_] CPU 0 >
[_] CPU 1 >
[_] CPU 2 >
...

where each entry contains the old menu (frequencies and governors as a submenu) and [_] is the icon which reflects
the state of the CPU on the current line.

I've only tested with two CPUs but it seems to work fine, so please patch against current trunk, test and enjoy.
Cheers
--
Kim.

Revision history for this message
Artem Popov (artfwo) wrote :

That's why I don't like per-CPU indicator approach.

Instead, I'm going to implement switching governors for all cores (and displaying something like the mean frequency for all of them, perhaps). I shall get back to this as soon as I finish my thesis. If anyone comes up with a patch before this, I'll gladly accept that.

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

> That's why I don't like per-CPU indicator approach.

What do you not like exactly ?

> Instead, I'm going to implement switching governors for all cores (and displaying something like the mean frequency for all of them, perhaps).

Hum... I don't really agree here. Either people care about CPU settings and they want fine grained control over them, or they
don't care and they wouldn't use the applet in the first place.
Also mean frequency is not really relevent. Say I have 4 cores which can switch from 800Mhz to 1.2Ghz. If one of them is
running wild at max frequency, I'd rather have the indicator show me that something is going 100%,
not that my whole system is going at 800*3 + 1200 / 4 = 900Mhz

I think it could be indeed good to also have a global setting but then it makes the assumption that all cores support
the same frequencies and all cores support the same governors. This is obviously the case for 99.9% of the people
but I dont know if there exists SMP conf for which you can have slightly different cpus.

Otherwise why not do the following:
- the main icon shows the state of fastest CPU.
- each CPU gets its line as above and there is an extra section below which sets globally for all cores
(or there could be an extra global entry which sets it for all cores).
[_] CPU 0 >
[_] CPU 1 >
[_] CPU 2 >
[_] CPU 3 >
--------------
1.2 Ghz
0.8 Ghz
--------------
Conservative
Ondemand
Performance
Powersave

> I shall get back to this as soon as I finish my thesis. If anyone comes up with a patch before this, I'll gladly accept that.

Best of luck with that.

Revision history for this message
Artem Popov (artfwo) wrote :

Right, showing the highest frequency among cores is reasonable. The fine-grained control however looks like bloat. Why on earth would you waste time navigating submenus and switching governors for every core, Kim?

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

Here is another take, which includes global setting.

http://www.lri.fr/~kn/files/indicator-cpufreq.png

I'm attaching indicator.py directly instead of a patch since I rewrote most of it.

Personally I find it nice to be able to switch cores separately (I had to do this recently
for benchmarking purposes. I admit that this is kind of a corner case though).
But of course it's also nice to be able to set the governor globally. I also like the idea
of have one icon per cpu in the submenu (instead of wasting space with N icons on
the top panel for N cores). This way I have pretty much the functionality from the
old panel applet, with only one status icon.

Anyway I'm certainly not asking you to merge it as is, I juste hacked something not too
ugly and thought I'd let people know about it.

Best.

Revision history for this message
István Kondor (kondor) wrote :

FWIW I'm in favor of being able to set the frequency for cores separately.
My reason is that my laptop tends to overheat when it's running at full speed. So I have to reduce the heat production a bit, but I still want one of the cores (I only have 2) running at full speed. I know that running BOINC on a notebook is probably not the wisest thing but hey, Linux is about choice.

Anyway, I support Kim's idea and hope that you'll accept it.

All the best,
Istvan

Revision history for this message
Marco Gavanelli (marco-gavanelli) wrote :

I used the old indicator because I run CPU intensive processes and I wanted to know when they finish.
I also think that knowing if some process is running wild is very useful. On the other hand, if you have two cores, and are running a CPU intensive process on one, having displayed only the maximum frequency will not tell you what happens on the other cores.
I like very much the idea by Karesz (comment #11); after all the space on the bar is wasted by the (useless) CPU icon more than by the thermometers icons.

Thanks for your great work!
Marco

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

Idea #11 seems nice but it's not easy to implement with the current app_indicator api. You can only set
the icon from an icon name (I'm not even sure it works with a filename, it has to be a symbolic name from
the current theme). So say you have 4 cores and 3 states (50, 75 and 100%) you would need 3^4 such pixmaps
in your theme... even if you could generate them on the fly it seems quite inefficient to save an icon on disk
and set the filename...

Revision history for this message
Marco Gavanelli (marco-gavanelli) wrote :

Well, 3^4 is not a big number, and each icon would cost only a few kB on your disk. Even if you plan to keep all of them in RAM, it would be about, say, 100kB? My system monitor says that currently indicator-cpufreq needs about 11MB of memory, so it would be an increase of less than 1%. And I guess most people do not have 4 cores with 3 CPUs (and, if they do they have quite a powerful system, so maybe they can waste some RAM for the icons).

Revision history for this message
Kim Nguyễn (kim.nguyen) wrote :

3^4 was just to give an idea... actually there are 4 states (25-50-75-100). And nowadays, 8 'cores' are not uncommon
(my desktop machine, a core i7 has 4 cores each of which with 2 hyperthreads, which show up as 8 processors).

I'm not arguing about the concept of having one bar/core in the main icon, actually I would love that, but implementing it
with the current app_indicator technology seems to be completely insane. This is *clearly* a place where allowing a gdkPixbuf
(or any kind of image buffer) for the icon would be useful, but libdbusmenu/appindicator do not allow that for now.

Revision history for this message
Artem Popov (artfwo) wrote :

Frequency is toggled for all cores now, renaming to track per-core switching in this bug instead.

summary: - Only one core managing with indicator-cpufreq.
+ Individual core frequency switching
Revision history for this message
Ken Sharp (kennybobs) wrote :

"> Instead, I'm going to implement switching governors for all cores (and displaying something like the mean frequency for all of them, perhaps).

Hum... I don't really agree here. Either people care about CPU settings and they want fine grained control over them, or they
don't care and they wouldn't use the applet in the first place."

That's absolute rubbish and a ridiculous assumption. I use it for exactly this reason to prolong the life of the battery, and restore full power as and when I need to.

"Frequency is toggled for all cores now, renaming to track per-core switching in this bug instead."

Has this been released? Does the current version do this or is it in the next release?

Revision history for this message
Artem Popov (artfwo) wrote :

The current version throttles frequency for all CPU cores simultaneously.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.