From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751240AbdFESGb (ORCPT ); Mon, 5 Jun 2017 14:06:31 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:36710 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751162AbdFESGa (ORCPT ); Mon, 5 Jun 2017 14:06:30 -0400 Subject: Re: [PATCH] sched: Introduce scaled capacity awareness in enqueue To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, vincent.guittot@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, Dhaval Giani 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> <20170602182621.gnpjs4fpvwze2hfr@hirez.programming.kicks-ass.net> From: Rohit Jain Message-ID: <6a613277-8e2c-4c05-1420-b288d15a036b@oracle.com> Date: Mon, 5 Jun 2017 11:08:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170602182621.gnpjs4fpvwze2hfr@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/02/2017 11:26 AM, Peter Zijlstra wrote: > 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. The global array is used to determine the threshold capacity, so that any CPU which lies below decides that a CPU is 'running low' on available capacity. This threshold can also be statically defined to be a fixed fraction, but having dynamic calculation to determine the threshold works for all benchmarks. Did you mean we should use a static cutoff and decide whether a CPU should be treated low on capacity and skip it during idle CPU search?