From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbaE0QO0 (ORCPT ); Tue, 27 May 2014 12:14:26 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:44327 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752804AbaE0QOZ (ORCPT ); Tue, 27 May 2014 12:14:25 -0400 Message-ID: <5384B9EE.10203@linaro.org> Date: Tue, 27 May 2014 18:14:38 +0200 From: Daniel Lezcano User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nicolas Pitre CC: Peter Zijlstra , Ingo Molnar , Vincent Guittot , Morten Rasmussen , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org Subject: Re: [PATCH v2 0/6] sched: expel confusing usage of the term "power" References: <1401142779-6633-1-git-send-email-nicolas.pitre@linaro.org> <53849C13.5010007@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/27/2014 06:02 PM, Nicolas Pitre wrote: > On Tue, 27 May 2014, Daniel Lezcano wrote: > >> On 05/27/2014 12:19 AM, Nicolas Pitre wrote: >>> "Power" is a very bad term in the scheduler context. There are so many >>> meanings that can be attached to it. And with the upcoming "power >>> aware" scheduler work, confusion is sure to happen. >>> >>> The definition of "power" is typically the rate at which work is performed, >>> energy is converted or electric energy is transferred. The notion of >>> "compute capacity" is rather at odds with "power" to the point many >>> comments in the code have to make it explicit that "capacity" is the >>> actual intended meaning. >>> >>> So let's make it clear what we man by using "capacity" in place of "power" >>> directly in the code. That will make the introduction of actual "power >>> consumption" concepts much clearer later on. >>> >>> This is based on the latest tip tree to apply correctly on top of existing >>> scheduler changes already queued there. >>> >>> Changes from v1: >>> >>> - capa_factor and SCHED_CAPA_* changed to be spelled "capacity" in full >>> to save peterz some Chupacabra nightmares >>> >>> - some minor corrections in commit logs >>> >>> - rebased on latest tip tree >>> >>> >>> arch/arm/kernel/topology.c | 54 +++---- >>> include/linux/sched.h | 8 +- >>> kernel/sched/core.c | 87 ++++++----- >>> kernel/sched/fair.c | 323 ++++++++++++++++++++------------------- >>> kernel/sched/sched.h | 18 +-- >>> 5 files changed, 246 insertions(+), 244 deletions(-) >> >> Hi Nico, >> >> it is a good initiative to replace the 'power' word by another to prevent >> confusion for future code. Personally I have a preference to 'strength' >> instead of 'capacity', in case that matter. > > Proper usage does matter: > > Strength could mean many things. Among them: > > Physical ability > > * Physical strength, as in people or animals > > As an abstract or psychological trait > > * Virtue and moral uprightness > * Courage or fortitude in the face of moral or social pressure > * Persuasiveness of an argument > * The exercise of willpower > > Physics > > * Strength of materials, ability to withstand an applied stress > without failure > + Compressive strength, capacity to withstand axially directed > pushing forces > + Tensile strength, maximum stress while being stretched or > pulled before necking > + Shear strength, the ability to withstand shearing > * Strength (explosive), the ability of an explosive to move > surrounding material > * Field strength, the magnitude of a field's vector > * Signal strength, the magnitude of an electric field at a > reference point > > I have difficulty referring to "CPU strength" without still be confused > about what exactly this would mean. None of the above definitions would > provide a sufficiently close analogy to be applied without ambiguity. Ok, fair enough. > On the other hand, the definition for capacity is much narrower: > > 1. > a. The ability to receive, hold, or absorb. > b. Abbr. c. A measure of this ability; volume. > > 2. The maximum amount that can be contained: a trunk filled to capacity. > > 3. > a. Ability to perform or produce; capability. > b. The maximum or optimum amount that can be produced: factories > operating below capacity. > > Etc. > > Here the analogy with "CPU capacity" or "compute capacity" is clear and > natural for what we are applying this term to. > > > Nicolas > -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog