linux-kernel - Re: ACPI regression in 2.6.29 - cpufreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Feb 2009 04:15:00 -0200
From:	Guilherme Malschitzky Schroeder <guilherme.m.schroeder@...il.com>
To:	Mattia Dongili <malattia@...ux.it>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ACPI regression in 2.6.29 - cpufreq_performance doesn't work

yeah mattia, you were right about ondemand module was being used on
cpu1, so i couldn't remove it.
with this commited patch, both cpu's can now have different speeds.
i was just comparing cat /proc/cpuinfo and didn't notice that cpu0 was
at 2268MHz.
cpufrequtils will need an update do deal with this change.
btw, this looks strange:

dub:~# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
dub:~# cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/scaling_governor
performance
ondemand

dub:~# cat /proc/cpuinfo | grep MH
cpu MHz         : 2268.000
cpu MHz         : 800.000

dub:~# cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/cpuinfo_cur_freq
2267000
2267000

dub:~# cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/scaling_min_freq
800000
800000

dub:~# cat /sys/devices/system/cpu/cpu{0,1}/cpufreq/scaling_available_frequencies
2268000 2267000 1600000 800000
2268000 2267000 1600000 800000

doesn't cpu0/cpufreq/scaling_min_freq needs to be 2268000 and
scaling_frequencies
just have 2268000 because it's set to "performance"?

am i forgetting anything else to set?

thanks,


On Tue, Feb 10, 2009 at 2:58 AM, Mattia Dongili <malattia@...ux.it> wrote:
> On Tue, Feb 10, 2009 at 01:53:13AM -0200, Guilherme Malschitzky Schroeder wrote:
>> Hi,
>>
>> If i set performance for scaling_governor using 2.6.29-rc4-git2,
>> ondemand stills control my CPU.
>> I get just 800MHz instead of 2268MHz.
>>
>> dub:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_cur_freq
>> 800000
>> dub:/sys/devices/system/cpu/cpu0/cpufreq# echo performance > scaling_governor
>> dub:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_governor
>> performance
>> dub:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_cur_freq
>> 2267000
>>
>> But, /proc/cpuinfo still shows 800MHz:
>>
>> model name      : Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz
>> stepping        : 6
>> cpu MHz         : 800.000
>>
>> And i cannot remove the ondemand module, that is not used anymore:
>>
>> dub:/sys/devices/system/cpu/cpu0/cpufreq# rmmod cpufreq_ondemand
>> ERROR: Module cpufreq_ondemand is in use
>
> yes, I guess it is used by cpu1, you should repeat the above commands
> for /sys/devices/system/cpu/cpu1/cpufreq too.
>
> ...
>> I've git bisect from 2.6.28.4 (which was working) to 2.6.29-rc4-git2
>> and i get into this:
>>
>> alemao@dub:~/linux-2.6$ git bisect good
>> d96f94c604453f87fe24154b87e1e9a3a72511f8 is first bad commit
>> commit d96f94c604453f87fe24154b87e1e9a3a72511f8
>> Author: Pallipadi, Venkatesh <venkatesh.pallipadi@...el.com>
>> Date:   Mon Feb 2 11:57:18 2009 -0800
>>
>>     ACPI: Enable bit 11 in _PDC to advertise hw coord
>>
>>     Bit 11 in intel PDC definitions is meant for OS capability to handle
>>     hardware coordination of P-states. In Linux we have always supported
>>     hwardware coordination of P-states. Just let the BIOSes know that we
>>     support it, by setting this bit.
>>
>>     Some BIOSes use this bit to choose between hardware or software coordination
>>     and without this change below, BIOSes switch to software coordination, which
>>     is not very optimal in terms of power consumption and extra
>> wakeups from idle.
>>
>>     Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
>>     Signed-off-by: Len Brown <len.brown@...el.com>
>
> the "coordination of P-states" is required when you have an SMP system
> that cannot scale cpu voltage independently on each cpu, so the best
> voltage/frequency have to be selected mediating between all the applied
> policies.
> The commit you found above just makes use hw coordination instead of sw
> and the message explains why.
>
> If you make sure you change *all* of the cpu policies you won't see the
> behaviour you describe.
>
> hth
> --
> mattia
> :wq
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/