Message-ID: <20090210110802.GB31755@kamineko.org>
Date:	Tue, 10 Feb 2009 20:08:02 +0900
From:	Mattia Dongili <malattia@...ux.it>
To:	Guilherme Malschitzky Schroeder <guilherme.m.schroeder@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ACPI regression in 2.6.29 - cpufreq_performance doesn't work

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Tue, Feb 10, 2009 at 04:15:00AM -0200, Guilherme Malschitzky Schroeder wrote:
> 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.

afair this has always been the case. the only difference the patch
introduces is telling the BIOS where the coordination is actually done.

> 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.

why? what's wrong with cpufrequtils?

> 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

well the former displays what the kernel thinks the frequency is, the
latter reads from hw registers and displays the real frequency.
It's consistent. The kernel doesn't (and can't) know about what the hw
is doing behind its back and present the user consistent information.

> 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?

no, if I understand your question correctly you're just misinterpreting
what those files are for, take a look at Documentation/cpu-freq

> 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/
> 
-- 
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/

Powered by blists - more mailing lists