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 S1751104AbbIQKVI (ORCPT <rfc822;w@1wt.eu>);
	Thu, 17 Sep 2015 06:21:08 -0400
Received: from mga14.intel.com ([192.55.52.115]:8061 "EHLO mga14.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751414AbbIQKVG (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 17 Sep 2015 06:21:06 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.17,546,1437462000"; 
   d="scan'208";a="807162926"
Date: Thu, 17 Sep 2015 10:31:41 +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: <20150917023141.GC11102@intel.com>
References: <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>
 <20150914125648.GJ27098@e105550-lin.cambridge.arm.com>
 <xm261te0vrav.fsf@sword-of-the-dawn.mtv.corp.google.com>
 <20150914225642.GB11102@intel.com>
 <xm26r3lza9pu.fsf@sword-of-the-dawn.mtv.corp.google.com>
 <20150915183950.GA28071@intel.com>
 <xm26mvwm9tv3.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: <xm26mvwm9tv3.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 Wed, Sep 16, 2015 at 10:06:24AM -0700, bsegall@google.com wrote:
> > The point really is, metrics (if not many ) need resolution, not just NICE_0_LOAD does. 
> > You can choose to either hardcode a number, like SCHED_CAPACITY_SHIFT now,
> > or you can use SCHED_RESOLUTION_SHIFT, which is even as simple as a sign to say what
> > the defined is (the scaled one with a better resolution vs. the original one).
> > I guess this is to say we now have a (no-big-deal) resolution system.
> 
> Yes they were chosen for similar reasons, but they are not conceptually
> related, and you couldn't decide to just bump up all the resolutions by
> changing SCHED_RESOLUTION_SHIFT, so doing this would just be misleading.

Yes, it appears they are made seemingly conceptually related. But probably 
it isn't worth a concern, if one knows it is just a scaled integer metric.