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 S1751187AbdFBS0c (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Jun 2017 14:26:32 -0400
Received: from merlin.infradead.org ([205.233.59.134]:44732 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750966AbdFBS0a (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Jun 2017 14:26:30 -0400
Date: Fri, 2 Jun 2017 20:26:21 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Rohit Jain <rohit.k.jain@oracle.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
        vincent.guittot@linaro.org, morten.rasmussen@arm.com,
        dietmar.eggemann@arm.com, Dhaval Giani <dhaval.giani@oracle.com>
Subject: Re: [PATCH] sched: Introduce scaled capacity awareness in enqueue
Message-ID: <20170602182621.gnpjs4fpvwze2hfr@hirez.programming.kicks-ass.net>
References: <1495486094-9097-1-git-send-email-rohit.k.jain@oracle.com>
 <20170530122831.5fyywtplq4jawj3j@hirez.programming.kicks-ass.net>
 <63736e6f-37e6-e287-a920-56ab0d0586b7@oracle.com>
 <20170601122827.5ptc3n47vvk2y7k7@hirez.programming.kicks-ass.net>
 <20170601123745.llebc4ur23d7t4fw@hirez.programming.kicks-ass.net>
 <f0805f09-b30f-9071-6c97-553597f3205c@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f0805f09-b30f-9071-6c97-553597f3205c@oracle.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jun 02, 2017 at 11:20:20AM -0700, Rohit Jain wrote:
> 
> On 06/01/2017 05:37 AM, Peter Zijlstra wrote:
> > On Thu, Jun 01, 2017 at 02:28:27PM +0200, Peter Zijlstra wrote:
> > > On Wed, May 31, 2017 at 03:19:46PM -0700, Rohit Jain wrote:
> > > 
> > > > > > 2) This scaled capacity is normalized and mapped into buckets.
> > > > > Why?
> > And its not at all clear why you'd need
> > that to begin with.
> 
> Here is the problem I am trying to solve:
> 
> The benchmark(s) have a high degree of variance when run multiple
> times.
> 
> We believe it is because of the scheduler not being aware of the scaled
> down capacity of the CPUs because of IRQ/RT activity.
> 
> This patch helps in solving the above problem. Do you have any thoughts
> on solving this problem in any other way?

Why does determining if a CPU's capacity is scaled down need to involve
global data? AFAICT its a purely CPU local affair.