On 15/12/15 15:32, Mark Rutland wrote: > On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote: > > On Tue, Dec 15, 2015 at 02:01:36PM +0000, Mark Rutland wrote: > > > > > I really don't want to see a table of magic numbers in the kernel. > > > > Right, there's pitfalls there too although not being part of an ABI > > does make them more manageable. > > I think that people are very likely to treat them exactly like an ABI, > w.r.t. any regressions in performance that result from their addition, > modification, or removal. That becomes really horrible when new CPUs > appear. > Yeah, and I guess the path towards out of three patches changing this values for a specifica platform (without exposing the same changes upstream) is not too far away. > > One thing it's probably helpful to establish here is how much the > > specific numbers are going to matter in the grand scheme of things. If > > the specific numbers *are* super important then nobody is going to want > > to touch them as they'll be prone to getting tweaked. If instead the > > numbers just need to be ballpark accurate so the scheduler starts off in > > roughly the right place and the specific numbers don't matter it's a lot > > easier and having a table in the kernel until we think of something > > better (if that ever happens) gets a lot easier. > > I agree that we first need to figure out the importance of these > numbers. I disagree that our first step should be to add a table. > My take is that ballpark is fine, but it's a per platform/configuration ballpark that we need. Not a per core-type one. > > My expectation is that we just need good enough, not perfect, and that > > seems to match what Juri is saying about the expectation that most of > > the fine tuning is done via other knobs. > > My expectation is that if a ballpark figure is good enough, it should be > possible to implement something trivial like bogomips / loop_per_jiffy > calculation. > I didn't really followed that, so I might be wrong here, but isn't already happened a discussion about how we want/like to stop exposing bogomips info or rely on it for anything but in kernel delay loops? Thanks, - 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
