On 24/02/15 10:21, Vincent Guittot wrote:
On 19 February 2015 at 18:18, Morten Rasmussen morten.rasmussen@arm.com wrote:
On Thu, Feb 19, 2015 at 04:52:41PM +0000, Peter Zijlstra wrote:
On Thu, Jan 15, 2015 at 11:09:25AM +0100, Vincent Guittot wrote:
[...]
Agreed. I think it is reasonable to assume that the arch code implementing arch_scale_freq_capacity() does it's best to make it fast for the particular architecture. Since the scaling factor to be returned by the function may be obtained in different ways for different architectures the caching should be done on the arch side.
But lets see, I've yet to see an actual implementation of it; and its got that sd argument, curious what you're going to do with that.
So we do have an RFC implementation for ARM already which I posted in December and is also included in the rather large RFC posting I did some weeks ago. That one basically reads two atomic variables and returns the ratio between the two. I have yet to benchmark how horribly expensive it is though. The sd argument is ignored. We might actually not need it at all?
For consistency across all arch_scale_xx_capacity, i would prefer to keep the same prototype interface (struct sched_domain *sd, int cpu) even if it's not used ofr now
Agreed.
Once we call arch_scale_xx_capacity [xx = freq, cpu] in the PELT code (i.e. w/ sd = NULL) we have to make sure that default_scale_cpu_capacity() can be called w/ sd = NULL too for platforms which are not providing their own arch_scale_cpu_capacity() function.
It's already part of '[RFCv3 PATCH 00/48] sched: Energy cost model for energy-aware scheduling'
https://lkml.org/lkml/2015/2/4/573
[...]