Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq
bru...@freebsd.org
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi
Responsible-Changed-By: brucec
Responsible-Changed-When: Thu Mar 25 08:29:06 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
Dan Lukes
From: Dan Lukes <d...@obluda.cz>
To: bug-fo...@FreeBSD.org, sp...@acm.poly.edu
Cc:
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq
Date: Thu, 25 Mar 2010 11:04:15 +0100
It sound like improper place for implementation of such logic.
Cpufreq is hardware driver - it allow others to control CPU speeds. It
do no own decisions nor should do (imho). When it should not do
decisions, then it's not appropriate place to store variables that exist
for the purpose of such decision process only.
cpufreq consumers (like powerd or acpi_thermal) are there for decision
making so such logic and configuration variables should be there.
The debug.cpufreq.lowest is here because some reported levels are not
usable in the real, not because someone decided he don't want to use it.
You may be interested that requested feature is implemented as part of
acpi_thermal. From man acpi_thermal:
hw.acpi.thermal.tz%d.passive_cooling
If set to 1, passive cooling is enabled. It does cooling without
fans using cpufreq(4) as the mechanism for controlling CPU speed.
Default is enabled for tz0 where it is available.
It require support from ACPI on your notebook which may or may not be
present. If such support is not present, so acpi_thermal can't help you,
then another "frequency decision" utility - e.g. - powerd - is
candidate-place to implement requested logic. No logic should belong to
cpufreq device driver itself, so no tunables for them there.
I noticed the argument "maximum on AC is another than maximum on
battery", but power state is available to powerd, so the logic we are
speaking about can count the power state as well. The only question is -
how to tell to powerd what we want from it exactly.
Dan
Nate Lawson
From: Nate Lawson <na...@root.org>
To: Dan Lukes <d...@obluda.cz>
Cc: bug-fo...@FreeBSD.org
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to
cpufreq
Date: Thu, 25 Mar 2010 09:06:04 -0700
Dan Lukes wrote:
> It sound like improper place for implementation of such logic.
>
> Cpufreq is hardware driver - it allow others to control CPU speeds. It
> do no own decisions nor should do (imho). When it should not do
> decisions, then it's not appropriate place to store variables that exist
> for the purpose of such decision process only.
>
> cpufreq consumers (like powerd or acpi_thermal) are there for decision
> making so such logic and configuration variables should be there.
>
> The debug.cpufreq.lowest is here because some reported levels are not
> usable in the real, not because someone decided he don't want to use it.
Exactly right. The "lowest" sysctl was there to prevent use of modes
that users said froze their laptop. It is not for scheduling/general
policy decisions. There is no reason for "highest" as this is a
scheduling decision. Such logic should be in powerd and such control
programs.
--
Nate
Boris Kochergin
frequency, respectively) options in powerd:
http://acm.poly.edu/~spawk/powerd/
It's for 7.0-RELEASE, so I will see if it needs to be brought up to date
and will file a PR.
-Boris
Nate Lawson
From: Nate Lawson <na...@root.org>
To: Boris Kochergin <sp...@acm.poly.edu>
Cc: bug-fo...@FreeBSD.org
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to
cpufreq
Date: Thu, 25 Mar 2010 11:08:52 -0700
Boris Kochergin wrote:
>
> OK. I also have code to implement -m and -M (minimum and maximum
> frequency, respectively) options in powerd:
>
> http://acm.poly.edu/~spawk/powerd/
>
> It's for 7.0-RELEASE, so I will see if it needs to be brought up to date
> and will file a PR.
Seems reasonable. Needs a little whitespace cleanup.
--
Nate
Boris Kochergin
From: Boris Kochergin <sp...@acm.poly.edu>
To: bug-fo...@FreeBSD.org
Cc: Nate Lawson <na...@root.org>
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to
cpufreq
Date: Fri, 26 Mar 2010 13:02:33 -0400
This PR can be closed. A new one with modernized patches to add support
for this in powerd is at bin/145063.
-Boris
jo...@freebsd.org
State-Changed-From-To: open->closed
State-Changed-By: joerg
State-Changed-When: Fri Mar 26 21:03:30 MET 2010
State-Changed-Why:
Closed upon Boris' request.