Thread (57 messages) 57 messages, 8 authors, 2015-12-17

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

From: Mark Rutland <mark.rutland@arm.com>
Date: 2015-12-15 18:10:31
Also in: linux-arm-kernel, linux-pm, lkml

On Tue, Dec 15, 2015 at 05:45:16PM +0000, 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.
Regardless of where the numbers live (DT or kernel), all we have are
numbers. I can see that changing the in-kernel numbers would be possible
when modifyign the DT is not, but I don't see how that gives you more
information.

Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help