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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA8D3C83F15 for ; Sat, 26 Aug 2023 20:27:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229758AbjHZU1U (ORCPT ); Sat, 26 Aug 2023 16:27:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229753AbjHZU1S (ORCPT ); Sat, 26 Aug 2023 16:27:18 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDE7BCF1 for ; Sat, 26 Aug 2023 13:27:14 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-3fee769fd53so17775465e9.1 for ; Sat, 26 Aug 2023 13:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20221208.gappssmtp.com; s=20221208; t=1693081633; x=1693686433; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=72TWidDa5V3wcjBf5rFQ2XFVxxhYZZuMbJHwfYjO6bA=; b=2TDhdcV9VXxzp4NxT5PJej22jakoZiFRsA1FJog+Hr2dQllce8U7PCMK7tsNwQPixP D8pV6SF1bNMMpPsMdACPcRphO9QAo5lBnZBe2fk49BfAjAFbn3xzaCQNPUhg9jcL+A8U ZNSAaovaj1SBT2CZnmE2yzQgh1AP4Ru4lcYwFv6fzkd9ltPuLxFzQxyMWts0nC3GNEaK 90t1hdjFwzqPZgjI0mL5fWxiP1ybzZ/aR5BVCM2AAdxOf2Y+y4Adc1Z2M1ECDfCI7FVw 61yqjiRFTIDL+XS/1rK+nzSgP9GMgACUVL5w9I3UVklHYA60mdilKGVb8ehv2ab5SOBt NTMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693081633; x=1693686433; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=72TWidDa5V3wcjBf5rFQ2XFVxxhYZZuMbJHwfYjO6bA=; b=hZiidjDjMbzbfTq5U53wO8Vm6ssHm7Bf7TV21Hmhs11oGAzUYsSm+xmn7CpMrA4Qsu juCovUTFwM3t2YgDVv/KRhgLX1nfLbgIASyyAKmdxwGWiQoPmD9Ou0PiiQ+vnUoCXyng DiwnvLVJv/Kno8hKtXyRndZ9hpMg8euECefh2BSlY99qRumiGTKfQMUPshs+huhXT1S0 pmZvmFWi7oSi+246Zx9EX+lfIfepK8cOz+bj2/AlLhKOgs/EOjRQxcKbbZN1YqLWwyMZ N4dj3HGabzxXm+XADp6fU395yfWP27n/hSz9iM/mnoolvcFT1xgVJShtrrwy5zOnv6PG tv8A== X-Gm-Message-State: AOJu0YySG9vWu9q4t2CWGAOkOX7trD1QGt3O94iGy/esW+qZmU7AiUX8 BZbHGk8n4Yp4Ja8U5EaI43Dfv8L32OzLsBcpJFA= X-Google-Smtp-Source: AGHT+IEBWYTe9P61o6OWH0KI80+a0++6wrib1qOUIkg87AJysBhqFjAvztbJd83CdAy3PQC+bJh/6g== X-Received: by 2002:a05:600c:2349:b0:3fb:ac9c:e6f with SMTP id 9-20020a05600c234900b003fbac9c0e6fmr17660116wmq.38.1693081632924; Sat, 26 Aug 2023 13:27:12 -0700 (PDT) Received: from airbuntu (host109-151-228-137.range109-151.btcentralplus.com. [109.151.228.137]) by smtp.gmail.com with ESMTPSA id x23-20020a1c7c17000000b003fbb1a9586esm9052160wmc.15.2023.08.26.13.27.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Aug 2023 13:27:12 -0700 (PDT) Date: Sat, 26 Aug 2023 21:27:11 +0100 From: Qais Yousef To: Dietmar Eggemann Cc: "Rafael J. Wysocki" , Viresh Kumar , Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Vincent Guittot , Lukasz Luba Subject: Re: [PATCH RFC 4/4] sched: cpufreq: Apply DVFS headroom to CFS only Message-ID: <20230826202711.n73r5wcpibdoiiba@airbuntu> References: <20230820210640.585311-1-qyousef@layalina.io> <20230820210640.585311-5-qyousef@layalina.io> <7fdfff24-80ed-acbf-810f-b641570141fd@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7fdfff24-80ed-acbf-810f-b641570141fd@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 08/21/23 18:41, Dietmar Eggemann wrote: > On 20/08/2023 23:06, Qais Yousef wrote: > > RT and Deadline have exact performance requirement when running. RT runs > > at max or a specific OPP defined by uclamp_min. Deadline's OPP is > > defined by its bandwidth. Both of which are known ahead of time and > > don't require a headroom to grow into. > > > > IRQs on the other hand have no specific performance requirement and > > cruises along at whatever the current OPP happens to be when they occur. > > > > Now they all have PELT pressure signals that does impact frequency > > selection and task placement. The question is do they need DVFS > > headroom? > > > > I think the answer is no because when CFS is not running at all, these > > pressure signal has no real impact on performance for RT, DL or IRQ. > > > > If CFS util is not zero, we already add their pressure as an > > *additional* headroom to account for the lost/stolen time. So I argue > > that the pressure are headroom themselves and shouldn't need an > > additional DVFS headroom applied on top. > > > > In summary final outcome should be: > > > > CFS + DVFS headroom + (RT, DT, IRQ) pressure headroom > > I assume here you want to align the difference that EAS deals with This function is used on all systems that use schedutil - EAS being one of them but not the only one. The definition isn't, and shouldn't, be tied to EAS. I'm certainly intending this change for all possible users of schedutil. > `util_cfs` vs `capacity` whereas power deals with `util` vs > `capacity_orig`? You want that power should only apply the 1.25 to util_cfs? I don't get what you're saying. But I think it's similar to what I'm saying. To clarify. What I'm saying is that when we try to calculate the effective util, CFS is the only entity in practice that interacts with DVFS. DL and RT by design 'disable' DVFS and when they become runnable set the frequency to a constant fixed point. For them DVFS latencies are not acceptable - although in practice they do take a single hit for the freq change on wake up. IRQ on the other hand doesn't really care about DVFS. So we end up in practice that CFS is the only entity that interacts with DVFS, so when we calculate the DVFS headroom, we should only take its util into account. Thanks! -- Qais Yousef