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 28337E743C8 for ; Thu, 28 Sep 2023 22:05:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231689AbjI1WFJ (ORCPT ); Thu, 28 Sep 2023 18:05:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230325AbjI1WFJ (ORCPT ); Thu, 28 Sep 2023 18:05:09 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D43D199 for ; Thu, 28 Sep 2023 15:05:07 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-405621baba7so107440355e9.0 for ; Thu, 28 Sep 2023 15:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1695938706; x=1696543506; darn=vger.kernel.org; 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=ArDC+M/Fj9/rymDfPmXsJ4SDmxJk6crmGXVQHrpZfh4=; b=KxgUIrtyjEy7/g8YMcZVf/n0F/JCfovtnretUayc4SYLldBYJCbnnCceGqxPW/Miqd 3RNI63iJQc5VimmYYqwCDEsdKQxKVnN/6QANip7pWG00xbep1l+a5N2e9qFIjxFyyYSc 5jsZeISsVmiRHZb7j0a1IHi+GgdGoo3eBeBhxOdiXXu9zRINyzx/RRHKanuIr+wLg/+8 yB/SEiIKcU3AiDB4vnhkSYPcVm+ioXrXqAry3IYMrEv+SiZeZUi4q3YdXco6N5AUaWZu us0LIvUOAmRQTF7EqKvTCF917s0s1fFO7x6+tppraeDlko7B2F1vHskMxYOLsukkOY1J jUFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695938706; x=1696543506; 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=ArDC+M/Fj9/rymDfPmXsJ4SDmxJk6crmGXVQHrpZfh4=; b=vUY/22M5ajtHlDiQ96ToFyZ4XgmphRAHTeuo4TYACZXec3PPYNenAeNpJex8As6A5t apmw8HPEK4zk955C35xJv9OKzOStvLT9cIhYUiS43aEt96AbxWD1FxjcrzbSc7nvTEBZ tQuphAnsxgSgVGFNyB9rWUnYvXby7O/5rEcJLfB92KBwx+mPfZbNTiwlzAfZI+EAOI8l u8SQy9ZITckkmudhnka9zYOlg4HYF5QFVfG5uWniqoVT5mdwJ00o0DE65eXiJNe7j/Tv FYUTPqZZrlEt7pfdJWn4tQY+o3pZSpDjsOnKX28A+hPcOyguaDXZLiT9j3glmyVT4BZ6 cUug== X-Gm-Message-State: AOJu0YzXfas4eRttDpWJHVr1R8AF35pyzAcSthCDAEYVR82qTizsj1Kt yRmyVdup9QqSFl4yAeH0kKReZA== X-Google-Smtp-Source: AGHT+IHU/EtVhwXCw30fq3cDxe4k2xBSQJzSV11vdm9krtEtk8XG/afGLewXVtCXSrWuuq7tQZnVaw== X-Received: by 2002:a05:600c:ad3:b0:402:e68f:888c with SMTP id c19-20020a05600c0ad300b00402e68f888cmr2387507wmr.7.1695938705848; Thu, 28 Sep 2023 15:05:05 -0700 (PDT) Received: from airbuntu (host109-151-228-137.range109-151.btcentralplus.com. [109.151.228.137]) by smtp.gmail.com with ESMTPSA id m5-20020a05600c280500b0040535648639sm74825wmb.36.2023.09.28.15.05.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 15:05:05 -0700 (PDT) Date: Thu, 28 Sep 2023 23:05:04 +0100 From: Qais Yousef To: Vincent Guittot Cc: "Rafael J. Wysocki" , Viresh Kumar , Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Dietmar Eggemann , Lukasz Luba Subject: Re: [PATCH 2/4] sched: cpufreq: Fix apply_dvfs_headroom() escaping uclamp constraints Message-ID: <20230928220504.gcft523kvt5jlfoi@airbuntu> References: <20230829163740.uadhv2jfjuumqk3w@airbuntu> <20230907215555.exjxho34ntkjmn6r@airbuntu> <20230910174638.qe7jqq6mq36brh6o@airbuntu> <20230916192509.bportepj7dbgp6ro@airbuntu> <20230924172301.7lqdcsnpqk7trtno@airbuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 09/28/23 19:50, Vincent Guittot wrote: > > > > Yep, absolutely. It seems we agree that CFS shouldn't go above 800 if it is > > capped even if there's headroom, but the question you have on the way it is > > At least I want to ensure that cpufreq has the right information to make a > smart decision. In the example above, it's not needed to go above 800 for > neither cfs nor irq. Okay you want to do even bigger rework :-) I thought I might have pushed some boundary with the rework I had in mind hehe. > I'm not in favor of showing all details to cpufreq because it will have to > follow the internal changes. In instead, I was thinking of something like: > > /* Function name to be changed */ > unsigned_long effective_cpu_util(int cpu, unsigned int *min, unsigned int *max) > > The function returns the actual utilization of the CPU and some minimum and > maximum limits with the possibility to have the min and/or Actual values > Max > because the min would be a hard minimum value whereas max only a soft maximum > value. > > Min would be the minimum perf to provide to the cpu : typically DL_bw + irq > Actual would be the actual utilization of the cpu: cfs+rt+dl+irq (after scaling > everything in the normal range) > Max would be the maximum needed performance for normal work: typically the > minimum between uclamp and capacity > > Then cpufreq can use these 3 values to compute a performance level and it > will know up to which perf level it should go and if it is worth it. > Something likr: Okay thanks! I think I have better clarity now. Let me try to rework the patches. Cheers -- Qais Yousef