Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754756AbbLKKIy (ORCPT ); Fri, 11 Dec 2015 05:08:54 -0500 Received: from foss.arm.com ([217.140.101.70]:60349 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754330AbbLKKIu (ORCPT ); Fri, 11 Dec 2015 05:08:50 -0500 Date: Fri, 11 Dec 2015 10:09:19 +0000 From: Juri Lelli To: Dietmar Eggemann Cc: Vincent Guittot , Rob Herring , linux-kernel , "linux-pm@vger.kernel.org" , LAK , "devicetree@vger.kernel.org" , Peter Zijlstra , Mark Rutland , Russell King - ARM Linux , Sudeep Holla , Lorenzo Pieralisi , Catalin Marinas , Will Deacon , Morten Rasmussen , Pawel Moll , Ian Campbell , Kumar Gala , Maxime Ripard , Olof Johansson , Gregory CLEMENT , Paul Walmsley , Linus Walleij , Chen-Yu Tsai , Thomas Petazzoni Subject: Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings Message-ID: <20151211100919.GH14571@e106622-lin> References: <1448288921-30307-1-git-send-email-juri.lelli@arm.com> <1448288921-30307-3-git-send-email-juri.lelli@arm.com> <20151124020631.GA15165@rob-hp-laptop> <20151124105423.GM26372@e106622-lin> <20151201112044.GV20439@e106622-lin> <566988D4.50406@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <566988D4.50406@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3512 Lines: 77 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 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/