On 05/02/16 09:30, Juri Lelli wrote:

On 04/02/16 16:46, Vincent Guittot wrote:

quoted

On 4 February 2016 at 16:44, Vincent Guittot [off-list ref] wrote:

quoted

On 4 February 2016 at 15:13, Juri Lelli [off-list ref] wrote:

quoted

On 04/02/16 13:35, Vincent Guittot wrote:

quoted

On 4 February 2016 at 13:16, Juri Lelli [off-list ref] wrote:

quoted

Hi Vincent,

On 04/02/16 13:03, Vincent Guittot wrote:

quoted

On 4 February 2016 at 10:36, Morten Rasmussen [off-list ref] wrote:

quoted

On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:

quoted

On 3 February 2016 at 12:59, Juri Lelli [off-list ref] wrote:

[...]

quoted

quoted

AFAICT, They don't have a dedicated cpufreq driver.

More generally speaking, it can take time before having

email sent before the ne d of the sentence ...

More generally speaking, it can take time before having a cpufreq
driver whereas we want to run and test scheduler behavior of these
heterogenous platform

I'm not familiar with this platform, but from what you are saying and
what I could find online, it looks like full Linux support is not
finished yet. Can we consider that as still in development? And if we
can do that, maybe is fair enough that we use the sysfs interface to
play with that platform until support is complete.

Do others have any opinion on this point?

IMHO, the solution should work for all of heterogeneous systems, (a) w/
cpufreq and driver, (b) w/ cpufreq and no driver loaded (yet) or (c) w/o
cpufreq.

That means that you can't put the benchmarking only into
cpufreq_register_driver() and rely on cpufreq policy topology.

Maybe you could do this for (b) and (c) inside an initcall and use
topology_core_cpumask() to figure out which cpu to profile?

This would then happen w/ the cpu frequency set by the fw.

But this then has to be synchronized somehow with the benchmarking
approach in cpufreq_register_driver().

[...]