Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752609AbbLJOOv (ORCPT ); Thu, 10 Dec 2015 09:14:51 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:50757 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbbLJOOt convert rfc822-to-8bit (ORCPT ); Thu, 10 Dec 2015 09:14:49 -0500 Subject: Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings To: Juri Lelli , Vincent Guittot 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> Cc: 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 From: Dietmar Eggemann Message-ID: <566988D4.50406@arm.com> Date: Thu, 10 Dec 2015 14:14:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151201112044.GV20439@e106622-lin> X-OriginalArrivalTime: 10 Dec 2015 14:14:44.0346 (UTC) FILETIME=[1E43EDA0:01D13355] X-MC-Unique: An9pY2vXQn6jaYpvitFNCg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3207 Lines: 69 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]). [...] -- 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/