Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6220214iob; Tue, 10 May 2022 13:09:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6TaxaNlOa9oAs4WaBT6e5ytpDj4Nx0moDB/KgfhYvp5/Di9IXQgnF07Q2/w9X18Af4LGw X-Received: by 2002:a05:6a00:c83:b0:50e:eea:1b9 with SMTP id a3-20020a056a000c8300b0050e0eea01b9mr21802427pfv.47.1652213388089; Tue, 10 May 2022 13:09:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652213388; cv=none; d=google.com; s=arc-20160816; b=JQ5o3GxaKt6TJKz5Paarf/Qd9SIX/YjdvN7KC7+aG0YMfe35AhdfmvZDeAgXbcohea Iu32eXxuHHkWF4p92MBM9NfEBT3nwlTmCKj8ztvwYGWf8QOSMQxeSrapMbi22PWwTiSA uiJuRSZ22TaXONH82aq43pTfZCST3xhEu+b7s87HiI4DE2L2deXg8igZmbhzJn7jVX1D ADgHZDtXptil0s7trNfBdrTJZXElxLz/J35jqSZQ/qcyAKArOtgxya1nYiTtXoUcsybW Dda0ik7oomWLC/Y7n0EMF+tSVHTF7I5i8fhRYFpjdQjj0SlhUVayZejS24rp00POn4Dw MpNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=iVhQfu9BvSel9bTLpKSfm4R4sf+0rQdEc6n58b7PopE=; b=DgNVCwiszbIFHaQ5/Y26HvSZV74j1l7I+9MBtXmkOFCv0XZ+WHZDJeVdW9vq1FLXuL qSje2MH3JgdKqbrEeYlP9BQaD1tXN96A48d3uGOCkPxQkCEVSbycA6oOmVkttE7+Fzr6 23KFfm6gshCD+DpuW7i0waIUCTcYxV90Nc3LcEauBQlZkMCyd3RHYr+d3+5a2HHpt7Gb +8eUomYEf2l/T6FgTaUxhkL9/qA5i7XH0qGJRxGCa429aOEtW5ro8/9L3YUwTmZ9uKlM j5ZkW6q8fachpTNGyYYYI3/ZrWHAZ4/F8xP/pM3L9OU/yeyzFEFSOysCK7tFLAzFfjXd 3oKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y28-20020a637d1c000000b003c61f2570dcsi266884pgc.586.2022.05.10.13.09.31; Tue, 10 May 2022 13:09:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345216AbiEJPTX (ORCPT + 99 others); Tue, 10 May 2022 11:19:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345467AbiEJPTA (ORCPT ); Tue, 10 May 2022 11:19:00 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 043B41D6750 for ; Tue, 10 May 2022 07:56:29 -0700 (PDT) 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 BF34012FC; Tue, 10 May 2022 07:56:28 -0700 (PDT) Received: from wubuntu (FVFF764EQ05P.cambridge.arm.com [10.1.34.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 30F6F3F73D; Tue, 10 May 2022 07:56:27 -0700 (PDT) Date: Tue, 10 May 2022 15:56:25 +0100 From: Qais Yousef To: Xuewen Yan Cc: Xuewen Yan , dietmar.eggemann@arm.com, lukasz.luba@arm.com, rafael@kernel.org, viresh.kumar@linaro.org, mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org, di.shen@unisoc.com Subject: Re: [PATCH] sched: Take thermal pressure into account when determine rt fits capacity Message-ID: <20220510145625.t5py7atlhgojsfyf@wubuntu> References: <20220421161509.asz25zmh25eurgrk@airbuntu> <20220425161209.ydugtrs3b7gyy3kk@airbuntu> <20220426092142.lppfj5eqgt3d24nb@airbuntu> <20220427105844.otru4yohja4s23ye@wubuntu> <20220503144352.lxduzhl6jq6xdhw2@airbuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Xuewen On 05/09/22 10:29, Xuewen Yan wrote: [...] > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index a68482d66535..44c7c2598d87 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -8399,16 +8399,37 @@ static unsigned long scale_rt_capacity(int cpu) > > > > static void update_cpu_capacity(struct sched_domain *sd, int cpu) > > { > > + unsigned long capacity_orig = arch_scale_cpu_capacity(cpu); > > unsigned long capacity = scale_rt_capacity(cpu); > > struct sched_group *sdg = sd->groups; > > + struct rq *rq = cpu_rq(cpu); > > > > - cpu_rq(cpu)->cpu_capacity_orig = arch_scale_cpu_capacity(cpu); > > + rq->cpu_capacity_orig = capacity_orig; > > > > if (!capacity) > > capacity = 1; > > > > - cpu_rq(cpu)->cpu_capacity = capacity; > > - trace_sched_cpu_capacity_tp(cpu_rq(cpu)); > > + rq->cpu_capacity = capacity; > > + trace_sched_cpu_capacity_tp(rq); > > + > > + if (static_branch_unlikely(&sched_asym_cpucapacity)) { > > + unsigned long inv_cap = capacity_orig - thermal_load_avg(rq); > > Indeed, I prefer arch_thermal_pressure here, because the > thermal_load_avg would change over time, > but the inv_cap's update period may could not keep up with his changes. If that's what works for you, I think that's fine. Vincent, Lukasz you okay with that? > > > + > > + rq->cpu_capacity_inverted = 0; > > + > > + for_each_possible_cpu(cpu) { > > + unsigned long cap = arch_scale_cpu_capacity(cpu); > > + > > + if (capacity_orig <= cap) > > + continue; > > + > > + if (cap > inv_cap) { > > + rq->cpu_capacity_inverted = inv_cap; > > + break; > > + } > > + } > > + > > + } > > > > sdg->sgc->capacity = capacity; > > sdg->sgc->min_capacity = capacity; > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > > index 8dccb34eb190..bfe84c870bf9 100644 > > --- a/kernel/sched/sched.h > > +++ b/kernel/sched/sched.h > > @@ -992,6 +992,7 @@ struct rq { > > > > unsigned long cpu_capacity; > > unsigned long cpu_capacity_orig; > > + unsigned long cpu_capacity_inverted; > > > > struct callback_head *balance_callback; > > > > @@ -2807,6 +2808,11 @@ static inline unsigned long capacity_orig_of(int cpu) > > return cpu_rq(cpu)->cpu_capacity_orig; > > } > > > > +static inline unsigned long cpu_in_capacity_inversion(int cpu) > > +{ > > + return cpu_rq(cpu)->cpu_capacity_inverted; > > +} > > + > > /** > > * enum cpu_util_type - CPU utilization type > > * @FREQUENCY_UTIL: Utilization used to select frequency > > > > > > --->8--- > > The patch is amazing for me, and the complexity is not too high. Would > you please push the patch? > I think the idea is yours, I don't want to use it as my patch v2. I'd be happy to add a commit message so that you can include it in your v2. First, I'd like to hear from Vincent and Lukasz they're happy with this approach. I've been trying to think how we can do this generically but can't find an alternative to the extra loop or additional fallback_cpu_mask. Maybe the mask is okay if we protect it with sched_asymmetric_cpucapacity static key.. Thanks -- Qais Yousef