On 06/07/12 21:04, Andriy Gapon wrote:
on 07/06/2012 11:38 Alexander Motin said the following:
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.
Not sure what you mean... I was talking about setting different CPUs to
different P-states based on the per-CPU conditions (e.g. utilization). I
certainly didn't mean to talk about heterogeneous P-state definitions or any
other heterogeneous silicon issues.
As you wish, but at this moment it is the only realistic application I
see. As I've told below, setting different frequencies to different
cores without scheduler awareness is a bad idea.
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.
I humbly disagree. I think that it's not a job of scheduler to be overly smart
when power-saving policies are in effect. IMO, scheduler should just do its own
job and powerd should react to individual loads of CPUs. Where latencies really
matter there powerd should not be used (or perhaps used with some different
policy skewed towards performance vs economy).
Scheduler usually operates in terms of milliseconds or less. powerd
operates in best case in terms of fractions of seconds (or it will eat
more power then save). Unless you are doing some heavy CPU-bound math
without any context switches, it won't work well without scheduler aware
about available computation resources.
> Also, Linux does it, so it must at least doable :-)
I don't know whether or how Linux does it. If you know how to do it
effectively -- welcome, be my guest. :)
--
Alexander Motin
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
