kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq

[Boris Kochergin]

Nate Lawson wrote:
> The following reply was made to PR kern/144232; it has been noted by GNATS.
>
> From: Nate Lawson <nate at root.org>
> To: Dan Lukes <dan at obluda.cz>
> Cc: bug-followup at 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
>   
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.

-Boris