Hi, On 10/12/15 14:14, Dietmar Eggemann wrote: > On 01/12/15 11:20, Juri Lelli wrote: > > Hi Vincent, > > > > On 30/11/15 10:59, Vincent Guittot wrote: > >> Hi Juri, > >> > >> On 24 November 2015 at 11:54, Juri Lelli <juri.lelli@xxxxxxx> wrote: > > [...] > > >>>>> +========================================== > >>>>> +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 -- 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
