CPUFreq addon in HAL

[Holger Macht]

On Tue 11. Jul - 13:18:47, Dave Jones wrote:
> On Tue, Jul 11, 2006 at 03:29:13PM +0200, Holger Macht wrote:
> 
>  > I thought about this possibility, too, but came to the conclusion that it
>  > doesn't make sense. There main reasons are:
>  > 
>  >   1. There are several dependencies between the different CPUs. The
>  >      cpufreq interfaces below /sys/devices/system/cpu/ lists all available
>  >      CPUs, each in one directory. However, you cannot assume that you can
>  >      simply control each CPU through it's single interface. Theres a file
>  >      affected_cpus in each directory listing the CPUs which are controlled
>  >      through this interface. So maybe it could look like:
>  > 
>  > 	cpu0/cpufreq/
>  > 		--> controls cpu0, cpu1
>  > 	cpu1/cpufreq/
>  > 		--> controls cpu0, cpu1
>  > 		...
>  > 
>  >      or:
>  > 	cpu0/cpufreq/
>  > 		--> controls cpu0, cpu1, cpu2, cpu3
>  > 		...
>  >      
>  >      or:
>  > 	cpu0/cpufreq/
>  > 		--> only controls cpu0
>  > 	cpu1/cpufreq/
>  > 		--> only controls cpu1
>  > 		...
>  > 		
>  >      I really don't want to export these dependencies. This would make
>  >      things unnecessarily compicated for higher level applications.
> 
> The notion of exposing CPUs to the app is perhaps misguided.
> Maybe it would be better to expose 'sockets' to the app.
> (There may still be valid use cases for exposing individual cores
>  too, so maybe this should be in addition)
> 
>  >   2. I can't imagine a use case were one might want to have different
>  >      settings for different CPUs.
> 
> I've been wondering the same thing recently, wondering why we bothered
> making the governors per-cpu.  For eg, it's nonsense to have ondemand on
> one core, and 'powersave' as the governor for the second core.
> 
> So far I've not heard any valid reasons for supporting this oddball usecase.
> 
>  > > Comments on the patch
>  > > 
>  > > > +int get_cpu_count(void)
>  > > 
>  > > Maybe use sysconf(3) here?
>  > 
>  > sysconf doesn't provide this information.
> 
> x86info has been using nrCPUs = sysconf(_SC_NPROCESSORS_CONF);
> for several years, and I don't recall getting a single bug report
> about that getting it wrong.

Ok, great, I didn't knew that but will use it of course. The sysconf
manpage seems to be a little bit outdated ;-)

Regards,
	Holger