[stable 9] broken hwpstate calls

[Alexander Motin]

On 06/07/12 11:10, Andriy Gapon wrote:
> on 07/06/2012 02:02 Jung-uk Kim said the following:
>> Any way, hwpstate still isn't quite right even without your patch.
>>
>> sys/kern/kern_cpu.c cpufreq_curr_sysctl() ->  CPUFREQ_SET() ->	/* for all
>> CPU devices */ cf_set_method() ->	/* thread_lock(), sched_bind(), ... */
>> CPUFREQ_DRV_SET() ->  sys/x86/cpufreq/hwpstate.c hwpstate_set() ->
>> hwpstate_goto_pstate()	/* for each CPU unit */ /* thread_lock(),
>> sched_bind(), ... */
>
> Oh, I didn't realize that there was the cpufreq-level loop over all CPUs!
> That really sucks.
>
> Maybe some day we should accept that different CPUs could legitimately be in
> different P-states and provide support for that throughout the stack (from
> powerd to drivers).

Support for different P-states on different CPUs can be useful if CPUs 
have different capabilities. I believe it is very rare, but possible. At 
this moment cpufreq should set for each CPU frequency closest to one 
that was set on BSP. It should be possible to make powerd to read sets 
of frequencies from all CPUs and do the same, just more intelligently.

Same time using very different frequencies for different CPUs can IMHO 
be very problematic even in theory. For SMP systems it is quite 
difficult (because of threads migration and possible inter-operations of 
multiple threads) to identify cases when even global frequency can be 
reduced without proportional performance penalty. Making in per-CPU 
multiplies number of options and requires awareness from the scheduler.

-- 
Alexander Motin