Bug 71841 - cpufreq ondemand ignore_nice_load doesn't work
Summary: cpufreq ondemand ignore_nice_load doesn't work
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: cpufreq
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-11 00:59 UTC by higuita
Modified: 2015-12-31 00:50 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.13.5
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description higuita 2014-03-11 00:59:28 UTC
I have a AMD64 cpu (opteron 175) and it use the powernow_k8 cpufreq drive. I'm using the ondemand governor and have enables the "ignore_nice_load". Yet, i'm right now compiling the kernel 3.15.6 and notice that the cpufreq is stick on the 1GHz instead of working on the expected 2.2GHz. The kernel compile is running on the default nice level (ie: 0 )

If i disable the "ignore_nice_load", the cpufreq jumps to the 2.2GHz. 


 00:23:17 /sys/devices/system/cpu/cpufreq/ondemand/$ for i in *; do echo  $i; cat $i ; done
ignore_nice_load
1
io_is_busy
0
powersave_bias
0
sampling_down_factor
1
sampling_rate
107000
sampling_rate_min
10000
up_threshold
50

 00:23:46 /sys/devices/system/cpu/cpufreq/ondemand/$ vmstat 5 
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 4  0      0 377948 157812 2752820    0    0   535   140 1191  768 73  8 15  3
 3  0      0 336640 157824 2753364    0    0    82    18 2718 1616 91  9  0  0
 3  0      0 347520 157832 2753688    0    0    18     2 2718 1601 92  8  0  0
 3  0      0 363204 157848 2754132    0    0    41   457 2823 1641 91  9  0  0
 3  0      0 396960 157856 2754488    0    0    44     2 2789 1681 90 10  0  0
^C

 00:24:43 /sys/devices/system/cpu/cpufreq/ondemand/$ cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 107 us.
  hardware limits: 1000 MHz - 2.20 GHz
  available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 1000 MHz and 2.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
analyzing CPU 1:
  driver: powernow-k8
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 107 us.
  hardware limits: 1000 MHz - 2.20 GHz
  available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 1000 MHz and 2.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).

 00:30:15 ~/$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 35
model name	: Dual Core AMD Opteron(tm) Processor 175
stepping	: 2
microcode	: 0x4d
cpu MHz		: 1000.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl extd_apicid pni lahf_lm cmp_legacy
bogomips	: 2002.43
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 35
model name	: Dual Core AMD Opteron(tm) Processor 175
stepping	: 2
microcode	: 0x4d
cpu MHz		: 1000.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl extd_apicid pni lahf_lm cmp_legacy
bogomips	: 2002.43
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
Comment 1 Len Brown 2014-10-28 04:12:47 UTC
/sys/devices/system/cpufreq/ondemand/ignore_nice_load
doesn't work on my Intel box either -- marking this bug as HW = "all".

For me, it fails in the opposite way.
When set, my system goes up to 3.8 GHz no matter
if a cycle soaker is invoked normally, or via nice(1).

I happen to be running Linux 3.13, as shipped by Ubuntu 14.04.1
Comment 2 Chen Yu 2015-12-17 05:26:59 UTC
The ignore_nice_load works on my side on 4.4-rc5, here's my testing step:

with ignore_nice_load enabled

1.root@Surface-Pro-3:/sys/devices/system/cpu/cpufreq/ondemand# echo 1 > ignore_nice_load

2.spin a nice(1) task on CPU2:
root@Surface-Pro-3:/sys/devices/system/cpu/cpufreq/ondemand# taskset -c 2 nice -n1 stress -c 1 -t 200


3.top result for CPU2 load:

top - 03:10:58 up 25 min,  4 users,  load average: 0.85, 0.44, 0.21
Tasks: 237 total,   2 running, 235 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa
%Cpu1  :  0.4 us,  0.4 sy,  0.0 ni, 99.2 id,  0.0 wa
%Cpu2  :  0.0 us,  0.0 sy,100.0 ni,  0.0 id,  0.0 wa
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa


4. turbostat -i 10
 CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz
       -     325   25.03    1300    2494
       0       1    0.05    1300    2494
       2    1297  100.00    1300    2494
       1       1    0.05    1300    2494
       3       0    0.03    1301    2494



5.  wait for step 4 to finish, then spin a nice(0) task on CPU 2:
root@Surface-Pro-3:/sys/devices/system/cpu/cpufreq/ondemand# taskset -c 2 stress -c 1 -t 200

6. top
top - 03:14:27 up 28 min,  4 users,  load average: 0.86, 0.61, 0.33
Tasks: 233 total,   2 running, 231 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa
%Cpu2  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa
%Cpu3  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa

7. turbostat -i 10

CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz
       -     724   25.01    2900    2494
       0       1    0.02    2842    2494
       2    2892   99.98    2900    2494
       1       0    0.02    2600    2494
       3       1    0.02    2601    2494
Comment 3 Chen Yu 2015-12-17 05:32:37 UTC
(In reply to higuita from comment #0)
> I have a AMD64 cpu (opteron 175) and it use the powernow_k8 cpufreq drive.
> I'm using the ondemand governor and have enables the "ignore_nice_load".
> Yet, i'm right now compiling the kernel 3.15.6 and notice that the cpufreq
> is stick on the 1GHz instead of working on the expected 2.2GHz. The kernel
> compile is running on the default nice level (ie: 0 )
> 
> If i disable the "ignore_nice_load", the cpufreq jumps to the 2.2GHz. 
> 
Could you please use 'top' to show the cpu load?(press '1' once top is running, then we can see how much percentage of nice on a specific CPU).
thanks
yu
Comment 4 Zhang Rui 2015-12-28 04:58:00 UTC
ping...
Comment 5 higuita 2015-12-30 17:49:17 UTC
hi

i'm now using a different cpu, a AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
that uses acpi-cpufreq...

testing in this with this cpu and a kernel 4.3.3 it works fine.

maybe this was fixed of just happen in certain HW configs?
Comment 6 Zhang Rui 2015-12-31 00:50:12 UTC
Well, it should relate to the HW config...
As it can not be reproduced now, I will close this bug.
Please feel free to re-open it if you can reproduce again with the same HW config in comment #0, or you can file a new bug report if it is reproduced with a different HW config.

Note You need to log in before you can comment on or make changes to this bug.