Re: About p4-clockmod breakage/removal

Re: About p4-clockmod breakage/removal

[Len Brown]

On Friday 09 May 2008, Alex Villací­s Lasso wrote:
> In a somewhat old computer I use at home, I have a Pentium 4 CPU running 
> at 1.7GHz. On this computer, acpi-cpufreq does not work (modprobe fails 
> with -ENODEV), only p4-clockmod. Lately this means I have to compile my 
> own kernel to get speed throttling on my computer.
> 
> Recently, patch ed9cbcd40004904dbe61ccc16d6106a7de38c998 (Revert 
> "speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1") 
> broke clock speed reporting. It now reports I have a max speed of 13.80 
> GHz instead of 1.7GHz. I only wish my CPU were that fast... Reverting 
> this patch fixes the problem for me. However, since I suscribed 
> yesterday to this list, I see talk about removing p4-clockmod altogether 
> from the tree. Maybe my real problem is that acpi-cpufreq does not work 
> even though it should, but I have yet to find a way to make the module 
> print the information that is supposed to be displayed through dprintk() 
> messages. What else can I do to debug acpi-cpufreq on my machine?

Assuming this is a laptop with a batter,
I'd certainly be interested if you could run BLTK
and measure any benefit to p4-clockmod (I've never
been able to)

http://www.lesswatts.org/projects/bltk/

Re: acpi-cpufreq
Verify that you're running the latest BIOS,
and look in BIOS SETUP for any options related
to CPU power management, Speed Step, EIST, P-states etc,
and enable if present.

If that doesn't do it, then open a bug here
complaining that acpi-cpufreq doesn't load:

http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI

and attach the output from acpidump -- which will tell
us if the underlying BIOS support is present.
My guess is that it is not.

-Len

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About p4-clockmod breakage/removal

[Matthew Garrett]

On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:

> Assuming this is a laptop with a batter,
> I'd certainly be interested if you could run BLTK
> and measure any benefit to p4-clockmod (I've never
> been able to)

The most plausible benefit to p4-clockmod is its utility in throttling 
the CPU if it would otherwise cause the system to overheat. From that 
point of view, I think it's worth keeping around - especially since not 
all machines expose T states via ACPI.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: About p4-clockmod breakage/removal

[Len Brown]

On Tuesday 13 May 2008, Matthew Garrett wrote:
> On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:
> 
> > Assuming this is a laptop with a batter,
> > I'd certainly be interested if you could run BLTK
> > and measure any benefit to p4-clockmod (I've never
> > been able to)
> 
> The most plausible benefit to p4-clockmod is its utility in throttling 
> the CPU if it would otherwise cause the system to overheat. From that 
> point of view, I think it's worth keeping around - especially since not 
> all machines expose T states via ACPI.

Matthew,
I'm delighted in your efforts to make Linux better, I really am.
So I'm sorry that for the 3rd message in a row I have to
completely disagree with you.

cpufreq is not designed to manage thermals, and putting p4_clockmod
underneath it to manage thermals is a mistake.

There is already a well known thermal throttling interface
available via ACPI and it does not need p4_clockmod to run.
Passive trip points work automatically even without cpufreq being present.
If they do not, then we need to fix them.

p4-clockmod should have been removed from the tree over a year ago.

-Len

Re: About p4-clockmod breakage/removal

[Matthew Garrett]

On Tue, May 13, 2008 at 11:35:32PM -0400, Len Brown wrote:

> cpufreq is not designed to manage thermals, and putting p4_clockmod
> underneath it to manage thermals is a mistake.

Check processor_thermal.c. It explicitly interfaces with cpufreq in 
order to perform P state management.

> There is already a well known thermal throttling interface
> available via ACPI and it does not need p4_clockmod to run.
> Passive trip points work automatically even without cpufreq being present.
> If they do not, then we need to fix them.

You're assuming that the throttling interface is always exposed via 
ACPI. I've seen machines where this isn't the case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: About p4-clockmod breakage/removal

[Len Brown]

On Wednesday 14 May 2008, Matthew Garrett wrote:
> On Tue, May 13, 2008 at 11:35:32PM -0400, Len Brown wrote:
> 
> > cpufreq is not designed to manage thermals, and putting p4_clockmod
> > underneath it to manage thermals is a mistake.
> 
> Check processor_thermal.c. It explicitly interfaces with cpufreq in 
> order to perform P state management.

The hook above is so that ACPI thermal throttling
does not invoke T-states until the more  efficient
P-states have already been exhausted.

It doesn't imply the presence of thermal awareness
anywhere in the cpufreq sub-system.

It also doesn't imply that running cpufreq on top
of T-states is a good idea.  Cpufreq as implemented,
say by the ondemand governor, is based
on the assumption that it is running on top of
P-states.  Deeper P-states result in
more efficient operation  (less energy/instruction)
due to their lower voltage, because energy varies with voltage^2.
T-states violate that assumpion and provide
all the performance cost with none of the efficiency
gains of P-states, because energy varies directly
with frequencey -- but so does performance cost.

> > There is already a well known thermal throttling interface
> > available via ACPI and it does not need p4_clockmod to run.
> > Passive trip points work automatically even without cpufreq being present.
> > If they do not, then we need to fix them.
> 
> You're assuming that the throttling interface is always exposed via 
> ACPI. I've seen machines where this isn't the case.

Please show me those machines.

thanks,
-Len

Re: About p4-clockmod breakage/removal

[Matthew Garrett]

On Wed, May 14, 2008 at 11:18:37AM -0400, Len Brown wrote:
> On Wednesday 14 May 2008, Matthew Garrett wrote:
> > Check processor_thermal.c. It explicitly interfaces with cpufreq in 
> > order to perform P state management.
> 
> The hook above is so that ACPI thermal throttling
> does not invoke T-states until the more  efficient
> P-states have already been exhausted.
> 
> It doesn't imply the presence of thermal awareness
> anywhere in the cpufreq sub-system.

The cpufreq sub-system itself isn't aware of thermal issues, but the 
ACPI system is. I'm not sure that the distinction's especially 
important.

> It also doesn't imply that running cpufreq on top
> of T-states is a good idea.  Cpufreq as implemented,
> say by the ondemand governor, is based
> on the assumption that it is running on top of
> P-states.  Deeper P-states result in
> more efficient operation  (less energy/instruction)
> due to their lower voltage, because energy varies with voltage^2.
> T-states violate that assumpion and provide
> all the performance cost with none of the efficiency
> gains of P-states, because energy varies directly
> with frequencey -- but so does performance cost.

Right. I'm not implying that this is a desirable situation, but the fact 
remains that some machines will reach critical shutdown temperature 
unless something is done to reduce the speed of the processor. If you 
don't have P states or ACPI-exposed T states, then p4-clockmod is about 
the best you can manage.

> > > There is already a well known thermal throttling interface
> > > available via ACPI and it does not need p4_clockmod to run.
> > > Passive trip points work automatically even without cpufreq being present.
> > > If they do not, then we need to fix them.
> > 
> > You're assuming that the throttling interface is always exposed via 
> > ACPI. I've seen machines where this isn't the case.
> 
> Please show me those machines.

http://www.google.co.uk/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=R8P&q=acpi+throttling+"<not+supported>"+-C3&btnG=Search&meta=

(a lot of false positives, but many of these are genuine)
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: About p4-clockmod breakage/removal

[Pavel Troller]

> On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:
> 
> > Assuming this is a laptop with a batter,
> > I'd certainly be interested if you could run BLTK
> > and measure any benefit to p4-clockmod (I've never
> > been able to)
> 
> The most plausible benefit to p4-clockmod is its utility in throttling 
> the CPU if it would otherwise cause the system to overheat. From that 
> point of view, I think it's worth keeping around - especially since not 
> all machines expose T states via ACPI.
> 
Hi!
  I heavily used p4-clockmod having old, broken battery. Using it and
throttling the CPU frequency immediately after AC disconnection was
necessary to limit the maximum current the CPU was able to drain from
the battery. Otherwise, the battery voltage would drop below the allowed
level and the machine would either switch off or crash. Yes, in idle state,
there was no change in the CPU power consumption, but during heavy CPU
load, 75% throttle really limited the power consumption to the level
allowing operation even with that old poor battery.
  So, p4-clockmod REALLY helped me a lot in this case. I vote for keeping
it on its place!
  With regards, Pavel Troller

Re: About p4-clockmod breakage/removal

[Len Brown]

On Wednesday 14 May 2008, Pavel Troller wrote:
> > On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:
> > 
> > > Assuming this is a laptop with a batter,
> > > I'd certainly be interested if you could run BLTK
> > > and measure any benefit to p4-clockmod (I've never
> > > been able to)
> > 
> > The most plausible benefit to p4-clockmod is its utility in throttling 
> > the CPU if it would otherwise cause the system to overheat. From that 
> > point of view, I think it's worth keeping around - especially since not 
> > all machines expose T states via ACPI.
> > 
> Hi!
>   I heavily used p4-clockmod having old, broken battery. Using it and
> throttling the CPU frequency immediately after AC disconnection was
> necessary to limit the maximum current the CPU was able to drain from
> the battery. Otherwise, the battery voltage would drop below the allowed
> level and the machine would either switch off or crash. Yes, in idle state,
> there was no change in the CPU power consumption, but during heavy CPU
> load, 75% throttle really limited the power consumption to the level
> allowing operation even with that old poor battery.
>   So, p4-clockmod REALLY helped me a lot in this case. I vote for keeping
> it on its place!
>   With regards, Pavel Troller

Yes, we could design Linux to be optimal for this broken hardware.
But the cost is that others with actual working hardware
unnwittingly run p4-clockmod and slow down their machine with
no energy savings benefit.

Perhaps there is a different workaround (besides purchasing
a battery or running on AC) that will help you?

Does this machine export /proc/acpi/processor/*/throttling?

-Len

Re: About p4-clockmod breakage/removal

[Henrique de Moraes Holschuh]

On Wed, 14 May 2008, Len Brown wrote:
> But the cost is that others with actual working hardware
> unnwittingly run p4-clockmod and slow down their machine with
> no energy savings benefit.

Well, there ARE ways to make sure p4-clockmod is only used as a last
ressort, and we CAN make sure the user will be told it is using a last
ressort measure that does not save energy.  Major nasty printks come to
mind.

p4-clockmod has saved my bacon on an Intel D875PBZ motherboard whose
processor was overheating, as well (older kernel, though. That box runs
2.6.16.y).  I can't check right now if that motherboard has proper ACPI
thermal zones that would do the same in a new kernel without
p4-clockmod, but I will do so when I have the chance.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: About p4-clockmod breakage/removal

[Thomas Renninger]

On Wed, 2008-05-14 at 01:56 +0100, Matthew Garrett wrote:
> On Tue, May 13, 2008 at 08:48:00PM -0400, Len Brown wrote:
> 
> > Assuming this is a laptop with a batter,
> > I'd certainly be interested if you could run BLTK
> > and measure any benefit to p4-clockmod (I've never
> > been able to)
> 
> The most plausible benefit to p4-clockmod is its utility in throttling 
> the CPU if it would otherwise cause the system to overheat. From that 
> point of view, I think it's worth keeping around - especially since not 
> all machines expose T states via ACPI.

If you think it's worth it..., but it needs a new implementation (at
another place). So just removing it for now should be best to avoid
further confusion.

Also there is another interface via mce:
arch/x86/kernel/cpu/mcheck/therm_throt.c

AFAIK this should be implemented in (all?) P4s, but Intel people should
know for sure.

This one should kick in for sure on high temperatures, are there any P4s
with a passive trip point defined?

I like the idea of reimplementing this via throttling interface. But
this is more for calming P4 users conscience (I saw my P4 running at 300
MHz on Windows) than for any real use.

   Thomas

Re: About p4-clockmod breakage/removal

[Matthew Garrett]

On Wed, May 14, 2008 at 01:36:14PM +0200, Thomas Renninger wrote:

> Also there is another interface via mce:
> arch/x86/kernel/cpu/mcheck/therm_throt.c
> 
> AFAIK this should be implemented in (all?) P4s, but Intel people should
> know for sure.

Hm. The MCE interface is only for reporting, rather than control. Do you 
know if it's possible to set the temperature at which the CPU will start 
its own throttling? That would potentially be more straightforward.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: About p4-clockmod breakage/removal

[Thomas Renninger]

On Wed, 2008-05-14 at 12:42 +0100, Matthew Garrett wrote:
> On Wed, May 14, 2008 at 01:36:14PM +0200, Thomas Renninger wrote:
> 
> > Also there is another interface via mce:
> > arch/x86/kernel/cpu/mcheck/therm_throt.c
> > 
> > AFAIK this should be implemented in (all?) P4s, but Intel people should
> > know for sure.
> 
> Hm. The MCE interface is only for reporting, rather than control. Do you 
> know if it's possible to set the temperature at which the CPU will start 
> its own throttling? That would potentially be more straightforward.

AFAIK there is not much to control from OS side.
All you get is an event, or better an exception, that BIOS detected too
high temperatures on the CPU and that your CPU is currently not running
at full speed.
The p4 parts seem to sit here:
arch/x86/kernel/cpu/mcheck/p4.c

You might find a hack to modify this, by reading P4 (this seem to sit in
the CPU itself?) or chipset specs. But again, is it worth it for a P4
where no power saving capabilities are present anyway?

  Thomas

Re: About p4-clockmod breakage/removal

[Matthew Garrett]

On Wed, May 14, 2008 at 02:49:18PM +0200, Thomas Renninger wrote:

> You might find a hack to modify this, by reading P4 (this seem to sit in
> the CPU itself?) or chipset specs. But again, is it worth it for a P4
> where no power saving capabilities are present anyway?

If the alternative is thermal shutdown, sure. I'll take a look through 
the specs.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: About p4-clockmod breakage/removal

[Len Brown]

On Wednesday 14 May 2008, Matthew Garrett wrote:
> On Wed, May 14, 2008 at 01:36:14PM +0200, Thomas Renninger wrote:
> 
> > Also there is another interface via mce:
> > arch/x86/kernel/cpu/mcheck/therm_throt.c
> > 
> > AFAIK this should be implemented in (all?) P4s, but Intel people should
> > know for sure.
> 
> Hm. The MCE interface is only for reporting, rather than control. Do you 
> know if it's possible to set the temperature at which the CPU will start 
> its own throttling? That would potentially be more straightforward.

No. this is hardware invoked thermal trottling, and the software
here is just trying to gracefully explain to you the reason
that your machine is running abnormally slow.

Software can not change the trip point for hardware thermal throttling.
It is set at the factory.  It is basically a hardware fail-safe mechanism,
and thus the trip point is set higher than that for ACPI thermal
throttling.

-Len