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 S1756247AbcEaGc7 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 31 May 2016 02:32:59 -0400
Received: from mga02.intel.com ([134.134.136.20]:41926 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755517AbcEaGcz (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 31 May 2016 02:32:55 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,394,1459839600"; 
   d="scan'208";a="991991453"
Date: Tue, 31 May 2016 06:35:31 +0800
From: Yuyang Du <yuyang.du@intel.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@kernel.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>
Subject: Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity
Message-ID: <20160530223531.GN18670@intel.com>
References: <1461958364-675-4-git-send-email-dietmar.eggemann@arm.com>
 <tip-cfa10334318d8212d007da8c771187643c9cef35@git.kernel.org>
 <20160512214811.GB8790@intel.com>
 <CAKfTPtBVPtnfP_7rUeFOO=XF8n7n1y=rA5p+5CdBVU8S00XdUQ@mail.gmail.com>
 <20160519153637.GA27946@e105550-lin.cambridge.arm.com>
 <20160523202401.GA18670@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160523202401.GA18670@intel.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 Tue, May 24, 2016 at 04:24:01AM +0800, Yuyang Du wrote:
> On Thu, May 19, 2016 at 04:36:38PM +0100, Morten Rasmussen wrote:
> > 
> > And this is exactly you get with this patch :-) load_above_capacity
> > (through max_pull) is multiplied by the group capacity to compute that
> > actual amount of [load] to remove:
> > 
> > env->imbalance 	= load_above_capacity * busiest->group_capacity /
> > 		 	SCHED_CAPACITY_SCALE
> > 
> > 		= 1*NICE_0_LOAD * 3*SCHED_CAPACITY_SCALE /
> > 			SCHED_CAPACITY_SCALE
> > 
> > 		= 3*NICE_0_LOAD
> > 
> > I don't think we disagree on how it should work :-) Without the capacity
> > scaling in this patch you get: 
> > 
> > env->imbalance = (6*SCHED_CAPACITY_SCALE - 3*SCHED_CAPACITY_SCALE) *
> > 			3*SCHED_CAPACITY_SCALE / SCHED_CAPACITY_SCALE
> > 
> > 		= 9*SCHED_CAPACITY_SCALE
> > 
> > Coming back to Yuyang's question. I think it should be NICE_0_LOAD to
> > ensure that the resulting imbalance has the proper unit [load].
> 
> Sorry, I'm still confused. After this patch, the unit is indeed [load], the
> load same as the weight visible to the user. However, you literally compared
> it with sg_lb_stats's avg_load and load_per_task, which has the unit of
> load_avg, which is scaled_load_down(NICE_0_LOAD). Am I missing something?

Hello?