linux-kernel - Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Dec 2015 14:14:44 +0000
From:	Dietmar Eggemann <dietmar.eggemann@....com>
To:	Juri Lelli <juri.lelli@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Rob Herring <robh@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	LAK <linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mark Rutland <mark.rutland@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sudeep Holla <sudeep.holla@....com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Olof Johansson <olof@...om.net>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Paul Walmsley <paul@...an.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Chen-Yu Tsai <wens@...e.org>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity
 bindings

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@....com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/