Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp167985rdh; Wed, 22 Nov 2023 23:48:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IFSKwkLfJE1RyRJ/DsJbNZc5H1QVP/MINWv382rSHgzEpyONS0mkBLjZxM37PhjZ+Wi6UB7 X-Received: by 2002:a17:902:ced1:b0:1cc:36fb:22ae with SMTP id d17-20020a170902ced100b001cc36fb22aemr3108585plg.2.1700725699459; Wed, 22 Nov 2023 23:48:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700725699; cv=none; d=google.com; s=arc-20160816; b=E4a4AUCgaY/IhBUvDMjiXwkAJ2lWzR0t2h49iHAnj7wHm/p3fe8WGYMnUXx9Q3uWcf nTXYJKad9i2DT4OBZ+WusABMdpxzj2TlSLeZwn/52k3Zd5Jd6YC0+wbgrn5yrIugsPsz YHCDCsy/sjnRTJFKAbtk+9sUIR9IiuAA2UZ7YZ/sL6LZDweWjuU9l2vWreNE0Ws5Q0Dd cyXdj5JFqn1bmg/Twi61lBBiXzuwsnJDaPqg7G3Sjg2r7354RweAhh8IU4rXPLQT18Ay kR98ZmU6H6dE6Ds4MgwTSwkv8p2PB0hRuFmGplyZah8qTBeIU2+Y0V097dUPg8Oy+AoX 3vBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Q2tnacSsEzYa51ZlaGyK1ojaRlmZcj0/ixkOd70T8dg=; fh=ubwYUnhB8uFX9aH0PJX1SlLxdEQxyoANHD1sjVzmSVo=; b=yAJ85C4aF58PZew2CK3FsXmVtztKYJ50DR0bb5HJjatT5b2yhiKHGzRKs8M/o0VRqq 0+GfLvX84WoDNKj9CGBhLWcEsAn/DhI61bjjOEPKtIc8HYj/B72HwYrjeB0ReRUfiSk3 rIzMHroRgJEF+DM2BLcc4aF9qSnZf95N76jSOLFk8uCLFpiwQuscEstsF6Q3lrfwW4cW 4CAZDUgDDFW1KzVnYRbg3QfF058QyfU+YC/FqxCSt/7LqI1cQbJdg3TpGPo3SE29zmgb SLPwJYBKu2lz9kXAh9vYN2YZa4Xsh3QrP3dGj3biQomK5jAYjt5SLrTQpSDMdX95oyh9 DKIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=d0Vbu6y0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id q15-20020a170902788f00b001cf5cae80e5si642530pll.114.2023.11.22.23.48.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 23:48:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=d0Vbu6y0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 57A09808002A; Wed, 22 Nov 2023 23:48:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230044AbjKWHrs (ORCPT + 99 others); Thu, 23 Nov 2023 02:47:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbjKWHrr (ORCPT ); Thu, 23 Nov 2023 02:47:47 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E987BA2 for ; Wed, 22 Nov 2023 23:47:53 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2802b744e52so1279983a91.0 for ; Wed, 22 Nov 2023 23:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1700725673; x=1701330473; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q2tnacSsEzYa51ZlaGyK1ojaRlmZcj0/ixkOd70T8dg=; b=d0Vbu6y0PEw2LZNM9GP05slLpLb4Y5WYnlL/fyUGpX1vmD5SdAnGitR8MpuARcBhOE +8981knXr0OtnpmBm536/+fBXaWVIVa3VkI7l0aJfbh+EZnhMlHun26Sh9yq5L4XcRCI yOg8bGn8rEP2p5qY9sGkAE/ZE5G++s2Jra1NCB94t8WlCwJT8Dxa2VKVBRavK3zXu8mm qjE6k7J2kVimcokbl+Zs3e+2o3O7aLtqnZeaO5WB4SNh84oqMsjydmFAji45TV2pCRCK M7wxIZj94BZ1VEAcpVZmjgaKOcmTJOhrYFX7A6DTdnWRk3gjRjSolZXtZgsvsOy//hTg mbgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700725673; x=1701330473; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q2tnacSsEzYa51ZlaGyK1ojaRlmZcj0/ixkOd70T8dg=; b=tdvKCS4rlfliiZnVc8IhX/QdjYW0dd1ITK7gOeMzw9O8bRfb0o/VHGMT3He03PBTWA bngeKn2NLRsgmYorGHClsO36PwKmaevyk/g3RciNmR2VzaAF7u/cihZaQqi05K1kWyaN bFb5OSruvbB/GQVXrzx5Kf0+sfjuCQ5SNSAp6a0trUOQqo2K28FK+nGoYAOIE5uOaqt2 yUzBHdmHe+k4sbpvoq5e4bema8Top9K4V3fQaVr80znoiIo1by86hXmvRGwriHo+D+yH /KvffiYw8jQBMMoj/Vxa6CVflC0myTKuQbGdDHTUQig5D4c/x3RAthVeDFHAqN8bKGAe Q52w== X-Gm-Message-State: AOJu0Yyraaf7I5bS1gcL3QbWR+bI4atY1YLJt89ozSUMkolS7M+NYNzm dB67GznhHotpJN9DVa1IJIVceQjKU4S2NLNHfS3+xA== X-Received: by 2002:a17:90a:dc08:b0:285:6622:ed1 with SMTP id i8-20020a17090adc0800b0028566220ed1mr1217400pjv.10.1700725673299; Wed, 22 Nov 2023 23:47:53 -0800 (PST) MIME-Version: 1.0 References: <20231103131821.1176294-1-vincent.guittot@linaro.org> <20231103131821.1176294-2-vincent.guittot@linaro.org> <20231114205422.k5m6y4m5vnw7dvzj@airbuntu> <20231121211725.gaekv6svnqdiq5l4@airbuntu> In-Reply-To: <20231121211725.gaekv6svnqdiq5l4@airbuntu> From: Vincent Guittot Date: Thu, 23 Nov 2023 08:47:42 +0100 Message-ID: Subject: Re: [PATCH v3 1/2] sched/schedutil: Rework performance estimation To: Qais Yousef Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, rafael@kernel.org, viresh.kumar@linaro.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, lukasz.luba@arm.com, wyes.karny@amd.com, beata.michalska@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 22 Nov 2023 23:48:05 -0800 (PST) On Wed, 22 Nov 2023 at 23:01, Qais Yousef wrote: > > On 11/22/23 08:38, Vincent Guittot wrote: > > > > > +unsigned long sugov_effective_cpu_perf(int cpu, unsigned long actual, > > > > + unsigned long min, > > > > + unsigned long max) > > > > +{ > > > > + struct rq *rq = cpu_rq(cpu); > > > > + > > > > + if (rt_rq_is_runnable(&rq->rt)) > > > > + return max; > > > > > > I think this breaks old behavior. When uclamp_is_used() the frequency of the RT > > > task is determined by uclamp_min; but you revert this to the old behavior where > > > we always return max, no? You should check for !uclamp_is_used(); otherwise let > > > the rest of the function exec as usual. > > > > Yes, I made a shortcut assuming that max would be adjusted to the max > > allowed freq for RT task whereas it's the min freq that is adjusted by > > uclamp and that should also be adjusted without uclamp. Let me fix > > that in effective_cpu_util and remove this early return from > > sugov_effective_cpu_perf() > > +1 > > > > Can we rename this function please? It is not mapping anything, but applying > > > a dvfs headroom (I suggest apply_dvfs_headroom()). Which would make the comment > > > also unnecessary ;-) > > > > I didn't want to add unnecessary renaming which often confuses > > reviewers so I kept the current function name. But this can the be > > rename in a follow up patch > > Okay. > > > > > static void sugov_get_util(struct sugov_cpu *sg_cpu) > > > > { > > > > - unsigned long util = cpu_util_cfs_boost(sg_cpu->cpu); > > > > - struct rq *rq = cpu_rq(sg_cpu->cpu); > > > > + unsigned long min, max, util = cpu_util_cfs_boost(sg_cpu->cpu); > > > > > > > > - sg_cpu->bw_dl = cpu_bw_dl(rq); > > > > - sg_cpu->util = effective_cpu_util(sg_cpu->cpu, util, > > > > - FREQUENCY_UTIL, NULL); > > > > + util = effective_cpu_util(sg_cpu->cpu, util, &min, &max); > > > > + sg_cpu->bw_min = map_util_perf(min); > > > > > > Hmm. I don't think we need to apply_dvfs_headroom() to min here. What's the > > > rationale to give headroom for min perf requirement? I think the headroom is > > > only required for actual util. > > > > This headroom only applies for bw_min that is used with > > cpufreq_driver_adjust_perf(). Currently it only takes cpu_bw_dl() > > It is also used in ignore_dl_rate_limit() - which is the user that caught my > eyes more. > > I have to admit, I always get caught out with the new adjust_perf stuff. The > down side of working on older LTS kernels for prolonged time :p > > > which seems too low because IRQ can preempt DL. So I added the average > > irq utilization into bw_min which is only an estimate and needs some > > headroom. That being said I can probably stay with current behavior > > for now and remove headroom > > I think this is more logical IMHO. DL should never need any headroom. And irq > needing headroom is questionable everytime I think about it. Does an irq storm > need a dvfs headroom? I don't think it's a clear cut answer, but I tend towards > no. > > > > And is it right to mix irq and uclamp_min with bw_min which is for DL? We might > > > > cpu_bw_dl() is not the actual utilization by DL task but the computed > > bandwidth which can be seen as min performance level > > Yep. That's why I am not in favour of a dvfs headroom for DL. > > But what I meant here is that in effective_cpu_util(), where we populate min > and max we have > > if (min) { > /* > * The minimum utilization returns the highest level between: > * - the computed DL bandwidth needed with the irq pressure which > * steals time to the deadline task. > * - The minimum performance requirement for CFS and/or RT. > */ > *min = max(irq + cpu_bw_dl(rq), uclamp_rq_get(rq, UCLAMP_MIN)); > > So if there was an RT/CFS task requesting a UCLAMP_MIN of 1024 for example, > bw_min will end up being too high, no? But at the end, we want at least uclamp_min for cfs or rt just like we want at least DL bandwidth for DL tasks > > Should we add another arg to sugov_effective_cpu_perf() to populate bw_min too > for the single user who wants it? > > > Thanks! > > -- > Qais Yousef