From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8560DC55179 for ; Fri, 23 Oct 2020 11:08:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3DF902192A for ; Fri, 23 Oct 2020 11:08:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S462785AbgJWLIp (ORCPT ); Fri, 23 Oct 2020 07:08:45 -0400 Received: from foss.arm.com ([217.140.110.172]:49534 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S462703AbgJWLIp (ORCPT ); Fri, 23 Oct 2020 07:08:45 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7D0B7113E; Fri, 23 Oct 2020 04:08:44 -0700 (PDT) Received: from [10.57.14.27] (unknown [10.57.14.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6A0F43F66B; Fri, 23 Oct 2020 04:08:40 -0700 (PDT) Subject: Re: [PATCH V2 1/2] sched/core: Rename and move schedutil_cpu_util() to core.c To: Viresh Kumar , Peter Zijlstra Cc: Ingo Molnar , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Quentin Perret , linux-pm@vger.kernel.org References: <80c66f55ac7f04b3ecd4ebf12d69d86c89480fa7.1603448113.git.viresh.kumar@linaro.org> <20201023103407.GK2594@hirez.programming.kicks-ass.net> <20201023105452.aivb5o6dws76evc3@vireshk-i7> From: Lukasz Luba Message-ID: Date: Fri, 23 Oct 2020 12:08:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20201023105452.aivb5o6dws76evc3@vireshk-i7> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/23/20 11:54 AM, Viresh Kumar wrote: > On 23-10-20, 12:34, Peter Zijlstra wrote: >> On Fri, Oct 23, 2020 at 03:50:20PM +0530, Viresh Kumar wrote: >>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >>> index d2003a7d5ab5..369ff54d11d4 100644 >>> --- a/kernel/sched/core.c >>> +++ b/kernel/sched/core.c >>> @@ -5117,6 +5117,119 @@ struct task_struct *idle_task(int cpu) >>> return cpu_rq(cpu)->idle; >>> } >>> >>> +/* >>> + * This function computes an effective utilization for the given CPU, to be >>> + * used for frequency selection given the linear relation: f = u * f_max. >>> + * >>> + * The scheduler tracks the following metrics: >>> + * >>> + * cpu_util_{cfs,rt,dl,irq}() >>> + * cpu_bw_dl() >>> + * >>> + * Where the cfs,rt and dl util numbers are tracked with the same metric and >>> + * synchronized windows and are thus directly comparable. >>> + * >>> + * The cfs,rt,dl utilization are the running times measured with rq->clock_task >>> + * which excludes things like IRQ and steal-time. These latter are then accrued >>> + * in the irq utilization. >>> + * >>> + * The DL bandwidth number otoh is not a measured metric but a value computed >>> + * based on the task model parameters and gives the minimal utilization >>> + * required to meet deadlines. >>> + */ >>> +unsigned long effective_cpu_util(int cpu, unsigned long util_cfs, >>> + unsigned long max, enum cpu_util_type type, >>> + struct task_struct *p) >>> +{ >> ... >>> +} >>> + >>> +unsigned long sched_cpu_util(int cpu, enum cpu_util_type type, >>> + unsigned long max) >>> +{ >>> + return effective_cpu_util(cpu, cpu_util_cfs(cpu_rq(cpu)), max, type, >>> + NULL); >>> +} >> >> Shouldn't all that be: #ifdef CONFIG_SMP ? > > I didn't realize that these matrices are only available in case of SMP > and that's why schedutil isn't available for !SMP. I wonder what we > should be doing in cpufreq_cooling now ? Make it depend on SMP ? Or > calculate load the traditional way (the stuff I just removed) for !SMP > case ? IMO the !SMP can leave with the old design, so keeping two implementations under #ifdef CONFIG_SMP is fair I would say in this case. There are popular platforms !SMP (BeagleBone, RPi1, RPiZero) but I haven't heard anyone was using IPA on them. Regards, Lukasz > > :) >