On 15/12/15 15:32, Mark Rutland wrote:

On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote:

quoted

On Tue, Dec 15, 2015 at 02:01:36PM +0000, Mark Rutland wrote:

quoted

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.

quoted

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.

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html