Hi,

On 15/12/15 17:45, Mark Brown wrote:

On Tue, Dec 15, 2015 at 05:28:37PM +0000, Mark Rutland wrote:

quoted

On Tue, Dec 15, 2015 at 05:17:13PM +0000, Mark Brown wrote:

quoted

quoted

Obviously people are going to get upset if we introduce performance
regressions - but that's true always, we can also introduce problems
with numbers people have put in DT.  It seems like it'd be harder to
manage regressions due to externally provided magic numbers since
there's inherently less information there.

quoted

It's certainly still possible to have regressions in that case. Those
regressions would be due to code changes in the kernel, given the DT
didn't change.

quoted

I'm not sure I follow w.r.t. "inherently less information", unless you
mean trying to debug without access to that DTB?

If what the kernel knows about the system is that it's got a bunch of
cores with numbers assigned to them then all it's really got is those
numbers.  If something changes that causes problems for some systems
(eg, because the numbers have been picked poorly but in a way that
happened to work well with the old code) that's not a lot to go on, the
more we know about the system the more likely it is that we'll be able
to adjust the assumptions in whatever new thing we do that causes
problems for any particular systems where we run into trouble.

quoted

quoted

My point there is that if we're not that concerned about the specific
number something in kernel is safer.

quoted

I don't entirely disagree there. I think an in-kernel benchmark is
likely safer.

Yes, I think that something where we just observe the system performance
at runtime is likely one of the best solutions if we can get something
that gives reasonable results.

quoted

quoted

That does have the issue that we need to scale with regard to the
frequency the benchmark gets run at.  That's not an insurmountable
obstacle but it's not completely trivial either.

quoted

If we change clock frequency, then regardless of where the information
comes from we need to perform scaling, no?

Yes, it's just a question of making the benchmarking bit talk to the
scaling bit so we know where we're at when we do the benchmark.  Like I
say it should be doable.

quoted

One nice thing about doing a benchmark to derive the numbers is that
when the kernel is that when the frequency is fixed but the kernel
cannot query it, the numbers will be representative.

Definitely.

OK, let's see how a dynamic approach could look like. As said, since it
was actually our first thought too, I already have a possible
implementation of such a thing. I'll be OOO until early Jan, but I'll
try to rebase what I have and post it here as soon as I'm back; and then
we see which solution looks better.

Thanks a lot for the feedback!

Best,

- Juri