Hi, On 15/12/15 17:45, Mark Brown wrote: > On Tue, Dec 15, 2015 at 05:28:37PM +0000, Mark Rutland wrote: > > On Tue, Dec 15, 2015 at 05:17:13PM +0000, Mark Brown wrote: > > > > 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. > > > 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. > > > 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. > > > > My point there is that if we're not that concerned about the specific > > > number something in kernel is safer. > > > 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. > > > > 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. > > > 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
