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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 88FBFC0650F for ; Mon, 5 Aug 2019 08:36:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 624BD217D9 for ; Mon, 5 Aug 2019 08:36:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564994171; bh=/OtRSIguKOv7zIsZgv8aLGiWOV71DQCuKF1WWLvQ/ts=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=KJoTKi3SsHA7ayyEOTGk2UFPGAg/QHX1dqQGY8MzR/87Vg/nkGMSBRnOMq3igqNbL uMs+m7VImdLd5W3yXAl0JSmB6GfpqRXSnz4gQtoJYNhJBABAwab3/GpFqhWl8vCYOl xzMezAUDuTwHOyhSfeQdVmr1+w5L/nnZrsSnGsZY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727857AbfHEIgK (ORCPT ); Mon, 5 Aug 2019 04:36:10 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:43713 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726423AbfHEIgK (ORCPT ); Mon, 5 Aug 2019 04:36:10 -0400 Received: by mail-oi1-f193.google.com with SMTP id w79so61503662oif.10; Mon, 05 Aug 2019 01:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/OtRSIguKOv7zIsZgv8aLGiWOV71DQCuKF1WWLvQ/ts=; b=sDiYfr8NyS7gO+VAZ/tBMzkDRBlvg22YhMutAcg7IZZD8FBJKbTuu0B8zqAm1TFmvO bVqk6ONOSRPhRqGbEBHzD3x+8y1xmpGwfmxtLbcMsXtJZuwc8E8yzgZ67V9iH6H4QHV2 KXkTga6XCnGZ7vGhOFuDw9ZQKjwsDXL8u+ZI012aIUoYZKMEFqIKWMgly7JvBZMWG9Zm uiYTmIiYqIQUxgLjLad2ngUO8BnEosBGCkD3lj+wzMnIt5vCLDwB7fsn9Ko/JjnVQwit UDKwU+QjZr0pOVr5pbIkYFyVO1BfvzsEKoiZy0+FRRmaC7S7a4T+WGb8VbkyTyTQjtTN Yi9A== X-Gm-Message-State: APjAAAUahoNaeZ2LpcT6Wkb6PkzgmCTAmfSNinHmnS3lIIAXZElczLDL 2gPORKDBLDIP3IAUTrLrKmFcUoE18Dj8RGQGl6g= X-Google-Smtp-Source: APXvYqzptRCEZ3O3VTh+dWJbaewHGMvttEmampT8Y6ZF/UP5Mp/uYEFm+nFP6TD3n8EPdgwQktQBzUqZ43EkMSyyGww= X-Received: by 2002:aca:5a41:: with SMTP id o62mr10383463oib.110.1564994169130; Mon, 05 Aug 2019 01:36:09 -0700 (PDT) MIME-Version: 1.0 References: <7dedb6bd157b8183c693bb578e25e313cf4f451d.1564724511.git.viresh.kumar@linaro.org> <23e3dee8688f5a9767635b686bb7a9c0e09a4438.1564724511.git.viresh.kumar@linaro.org> <2676200.jfxhmTd764@kreacher> <000401d54a0c$2f03aa50$8d0afef0$@net> In-Reply-To: <000401d54a0c$2f03aa50$8d0afef0$@net> From: "Rafael J. Wysocki" Date: Mon, 5 Aug 2019 10:35:54 +0200 Message-ID: Subject: Re: [PATCH V3 2/2] cpufreq: intel_pstate: Implement ->resolve_freq() To: Doug Smythies Cc: "Rafael J. Wysocki" , Viresh Kumar , Srinivas Pandruvada , Len Brown , Linux PM , Vincent Guittot , "v4 . 18+" , Doug Smythies , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 3, 2019 at 5:00 PM Doug Smythies wrote: > > On 2019.08.02 02:28 Rafael J. Wysocki wrote: > > On Friday, August 2, 2019 11:17:55 AM CEST Rafael J. Wysocki wrote: > >> On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar wrote: > >>> > >>> Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files, > >>> which can be used to force a limit on the min/max P state of the driver. > >>> Though these files eventually control the min/max frequencies that the > >>> CPUs will run at, they don't make a change to policy->min/max values. > >> > >> That's correct. > >> > >>> When the values of these files are changed (in passive mode of the > >>> driver), it leads to calling ->limits() callback of the cpufreq > >>> governors, like schedutil. On a call to it the governors shall > >>> forcefully update the frequency to come within the limits. > >> > >> OK, so the problem is that it is a bug to invoke the governor's ->limits() > >> callback without updating policy->min/max, because that's what > >> "limits" mean to the governors. > >> > >> Fair enough. > > > > AFAICS this can be addressed by adding PM QoS freq limits requests of each CPU to > > intel_pstate in the passive mode such that changing min_perf_pct or max_perf_pct > > will cause these requests to be updated. > > All governors for the intel_cpufreq (intel_pstate in passive mode) CPU frequency > scaling driver are broken with respect to this issue, not just the schedutil > governor. Right. My point is that that changing min_perf_pct or max_perf_pct should cause policy limits to be updated (which is not the case now) instead of running special driver code on every frequency update just in case the limits have changed in the meantime.