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 16:42:11
Also in: linux-arm-kernel, linux-pm, lkml

On Tue, Dec 15, 2015 at 04:23:18PM +0000, Catalin Marinas wrote:
On Tue, Dec 15, 2015 at 03:57:37PM +0000, Mark Rutland wrote:
quoted
On Tue, Dec 15, 2015 at 03:46:51PM +0000, Juri Lelli wrote:
quoted
On 15/12/15 15:32, Mark Rutland wrote:
quoted
On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote:
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?
I meant that we could have a benchmark of that level of complexity,
rather than those specific values.
Or we could simply let user space use whatever benchmarks or hard-coded
values it wants and set the capacity via sysfs (during boot). By
default, the kernel would assume all CPUs equal.
I assume that a userspace override would be available regardless of
whatever mechanism the kernel uses to determine relative
performance/effinciency.

I am not opposed to that mechanism being "assume equal".

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