From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751216AbdEaWRr (ORCPT ); Wed, 31 May 2017 18:17:47 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:17712 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbdEaWRq (ORCPT ); Wed, 31 May 2017 18:17:46 -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 References: <1495486094-9097-1-git-send-email-rohit.k.jain@oracle.com> <20170530122831.5fyywtplq4jawj3j@hirez.programming.kicks-ass.net> From: Rohit Jain Message-ID: <63736e6f-37e6-e287-a920-56ab0d0586b7@oracle.com> Date: Wed, 31 May 2017 15:19:46 -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: <20170530122831.5fyywtplq4jawj3j@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: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/30/2017 05:28 AM, Peter Zijlstra wrote: > On Mon, May 22, 2017 at 01:48:14PM -0700, Rohit Jain wrote: >> The patch introduces capacity awarness in scheduler (CAS) which avoids >> CPUs which might have their capacities reduced (due to IRQ/RT activity) >> when trying to schedule threads (on the push side) in the system. This >> awareness has been added into the fair scheduling class. >> >> It does so by, using the following algorithm: >> -------------------------------------------------------------------------- >> 1) As in rt_avg the scaled capacities are already calculated. >> >> 2) This scaled capacity is normalized and mapped into buckets. > Why? This is done to deterministically define the CPUs which are low on capacities. By mapping it into buckets it becomes easier to do a percentile calculation. >> 3) Any CPU which lies below the 80th percentile in terms of percentage >> capacity available is considered as a low capacity CPU. > Random number; can we do better? What does existing code do? > Existing code checks to see if the waker is running on a CPU with better capacity than the 'previous cpu'. If that is the case the waker cpu is provided as 'target' to select_idle_sibling. (When I say capacity this is not the scaled one because of IRQ, RT, etc.) However, in case this 'target' is not an idle CPU, the rest of select_idle_sibling would ignore the capacities altogether.