Date: Thu, 25 Mar 2010 16:30:04 GMT From: Nate Lawson <nate@root.org> To: freebsd-acpi@FreeBSD.org Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq Message-ID: <201003251630.o2PGU4GZ014200@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/144232; it has been noted by GNATS. From: Nate Lawson <nate@root.org> To: Dan Lukes <dan@obluda.cz> Cc: bug-followup@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003251630.o2PGU4GZ014200>