From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754438AbbILCO0 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 11 Sep 2015 22:14:26 -0400
Received: from mga02.intel.com ([134.134.136.20]:30931 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752779AbbILCOY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 11 Sep 2015 22:14:24 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,515,1437462000"; 
   d="scan'208";a="767434121"
Date: Sat, 12 Sep 2015 02:24:51 +0800
From: Yuyang Du <yuyang.du@intel.com>
To: bsegall@google.com
Cc: Morten Rasmussen <morten.rasmussen@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Steve Muckle <steve.muckle@linaro.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
        "mturquette@baylibre.com" <mturquette@baylibre.com>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        Juri Lelli <Juri.Lelli@arm.com>,
        "sgurrappadi@nvidia.com" <sgurrappadi@nvidia.com>,
        "pang.xunlei@zte.com.cn" <pang.xunlei@zte.com.cn>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/6] sched/fair: Get rid of scaling utilization by
 capacity_orig
Message-ID: <20150911182451.GA11102@intel.com>
References: <55EDAF43.30500@arm.com>
 <CAKfTPtBmgc=7JMRcTL9VYdHxb7qgXBDFc62rb-jnSVCePwJNsg@mail.gmail.com>
 <55EDDD5A.70904@arm.com>
 <CAKfTPtA0N-YTFMpN8-8ZbwakcsaY7=N4gnM5JivzCWsZnRRezQ@mail.gmail.com>
 <55EED99E.2040100@arm.com>
 <20150909201519.GB21833@intel.com>
 <20150910100727.GU3644@twins.programming.kicks-ass.net>
 <20150911002825.GA3014@intel.com>
 <20150911103059.GH27098@e105550-lin.cambridge.arm.com>
 <xm26a8ssvqby.fsf@sword-of-the-dawn.mtv.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xm26a8ssvqby.fsf@sword-of-the-dawn.mtv.corp.google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 11, 2015 at 10:05:53AM -0700, bsegall@google.com wrote:
> 
> SCHED_LOAD_RESOLUTION and the non-SLR part of SCHED_LOAD_SHIFT are not
> required to be the same value and should not be conflated.
 
> In particular, since cgroups are on the same timeline as tasks and their
> shares are not scaled by SCHED_LOAD_SHIFT in any way (but are scaled so
> that SCHED_LOAD_RESOLUTION is invisible), changing that part of
> SCHED_LOAD_SHIFT would cause issues, since things can assume that nice-0
> = 1024. However changing SCHED_LOAD_RESOLUTION would be fine, as that is
> an internal value to the kernel.
>
> In addition, changing the non-SLR part of SCHED_LOAD_SHIFT would require
> recomputing all of prio_to_weight/wmult for the new NICE_0_LOAD.

Not fully looked into the concerns, but the new SCHED_RESOLUTION_SHIFT
is intended to formalize all the integer metrics that need better resolution.
It is not special to any metric, so actually it is to de-conflate whoever is
conflated.