[Bug 58761] related_cpus truncated with acpi-cpufreq driver on kernel 3.9.3

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58761





--- Comment #16 from Benoit Pradelle <b.pradelle@gmail.com>  2013-05-30 20:00:30 ---
(In reply to comment #15)
> (In reply to comment #14)
> > I totally agree with Jean-Philippe: some information is lost with the 3.9
> > version and this information *is* useful to correctly set CPU frequencies. So
> > either the related_cpus field meaning should be restored or a new field should
> > be added.
> > 
> > If you doubt that such information is valuable, please consider all the runtime
> > DVFS controllers such as beta adaptive [1], or CPU MISER [2]. Those systems, to
> > be ported on current multicore processors, have to take a great care of the
> > actually applied CPU frequency (not only that requested per core but the one
> > actually in use). If it is impossible to determine what cores share the same
> > frequency, it is impossible to perform such kind of DVFS on multicore CPUs in a
> > portable way.
> > 
> 
> Exactly it is not possible to tell what frequency the core will run at unless
> the same pstate is requested for all cores.  Even then it is not guaranteed in
> the presence of thermal throttling.
> 
> You do NOT have positive control over the frequency the core runs at.  You
> requested your desired performance level and the processor ensures that you get
> it.
> 
> The papers below reference processors that did not have this functionality. the
> assumptions about frequency control no longer hold (at least for current Intel
> Processors).
> 

OK I understand your point. However, even if in some cases (thermal threshold
reached, TurboBoost, ...) the processors ignores/goes beyond the users
requests, most of the time, when the user requests a frequency, it is
effectively set by the processor. So, yes, the users still have some sort of
control over CPU frequency in the general case (even if it went from precise
frequency control to performance level requests) and it matters a lot when
building and experimenting new DVFS controlers.

Going back to the topic, people are designing DVFS controlers and have to be
aware of the cores using the same frequency in order to achieve efficient
frequency control on multicore processors. A file was previously stating that
relation so it should not be such a big deal to restore the same information in
another file. Isn't it?

> 
> > If you think that related_cpus is misleading (and I'd totally agree with you on
> > that), then maybe a new field is required.
> > 
> > 
> > [1] C.-h. Hsu and W.-c. Feng, “A power-aware run-time system for
> > high-performance computing,” in Proceedings of the 2005 ACM/IEEE conference on
> > Supercomputing.
> > [2] R. Ge, X. Feng, W. chun Feng, and K. Cameron, “CPU MISER: A
> > performance-directed, run-time system for power-aware clusters,” in Parallel
> > Processing, 2007. ICPP 2007.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.