Hi,

On 10/12/15 14:14, Dietmar Eggemann wrote:

On 01/12/15 11:20, Juri Lelli wrote:

quoted

Hi Vincent,

On 30/11/15 10:59, Vincent Guittot wrote:

quoted

Hi Juri,

On 24 November 2015 at 11:54, Juri Lelli [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

quoted

+==========================================
+3 - capacity-scale
+==========================================
+
+CPUs capacities are defined with respect to capacity-scale property in the cpus
+node [1]. The property is optional; if not defined a 1024 capacity-scale is
+assumed. This property defines both the highest CPU capacity present in the
+system and granularity of CPU capacity values.

I don't really see the point of this vs. having an absolute scale.

IMHO, we need this for several reasons, one being to address one of your
concerns below: vendors are free to choose their scale without being
forced to publish absolute data. Another reason is that it might make
life easier in certain cases; for example, someone could implement a
system with a few clusters of, say, A57s, but some run at half the clock
of the others (e.g., you have a 1.2GHz cluster and a 600MHz cluster); in
this case I think it is just easier to define capacity-scale as 1200 and
capacities as 1200 and 600. Last reason that I can think of right now is
that we don't probably want to bound ourself to some particular range
from the beginning, as that range might be enough now, but it could
change in the future (as in, right now [1-1024] looks fine for
scheduling purposes, but that might change).

Like Rob, i don't really see the benefit of this optional
capacity-scale property. Parsing the capacity of all cpu nodes should
give you a range as well.
IMHO, this property looks like an optimization of the code that will
parse the dt more than a HW description

I agree that we can come up with the same information just looking at
the biggest capacity value of all CPUs and treat that value as
capacity-scale. I just thought that having that explicit made things
clearer, as it could be not easy to immediately see from a DT with many
CPUs which is the biggest capacity value. But, yes, we could remove that
anyway.

+1! This capacity-scale complicates things unnecessarily. It was hard
for me to understand the meaning of it. Your 2. example sets
'capacity-scale = <2>' but also 'capacity = <2>' for cpu[01] and
'capacity = <1>' for cpu[23]. This can be easily replaced by 'capacity =
<1024>' for cpu[01] and 'capacity = <512>' for cpu[23]. Much more
readable, as it was mentioned already in this thread.

I understand that we don't want to limit the range of capacity values in
the dt file to [1..1024] nor enforce that the cpu w/ the highest
capacity has to have the value of 1024 in the dt file so the scheduler
has to scale accordingly if we want to limit capacity to its supported
capacity range (like with EAS [1..1024]).

OK, I guess I can easily remove capacity-value and simply normalize CPU
capacities w.r.t. the highest capacity in the DT.

Thanks,

- Juri