Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3680028pxb; Mon, 9 Nov 2020 18:49:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzz8l7rTZmhj4Htv0XFdOoRNip2DWsJ3hClNk3ayaOfJ+yHtNGKmw3wysAup/OsaDnl2BXC X-Received: by 2002:a17:906:114b:: with SMTP id i11mr17426198eja.106.1604976554450; Mon, 09 Nov 2020 18:49:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604976554; cv=none; d=google.com; s=arc-20160816; b=QlwqC/VPNZqC/6fNnfZXY4iAfyJmksRb6U0oXT2c6kUxr8un3tPcCxDjc1a26eYPxN Uqse6UchHcWGdxpjuO35d3Z4DUcHGrtGxs+OE+CgVR1Qn9GRRS5cdU69RikD1wklpJfF XjkwBi5TinU5XhK3M1M/Mla4D/iVrk+aXv+RNo7BFASGh+BYf2hGmSbMvA+oai8Rcy2w Wf3Jr6aJpVt0E7uAjcsYSYEDGqXy76GOrTXjcOh6KmPZddt7ZC6xL9gS6JdPW9gk8z6+ iIGUrB9xN6lyRauzuru8OKv5ACW/ARv70oBCfsPxRZOpaeD7Rh8xyOowbusG8UTOzc9E 68Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=6UuLx7prIHda8827z12iEWkf6vSvIP09lTJVmS5Ox0Q=; b=gDjMbe0q/i/TAwB1n++4Vk8prJNIrWYIM5rTOha/+KXKSuKH9n9fZMt48DaqHVul4e d8XCZcq/Wr3AWmGlJBZ2EJs7UamQo53ef/K8l7jNl2gsbnpY1fdEmrlsuJtHvk0u0dz3 3nJt50DQdE2epfdArllZ6jHkiCwi7SrJ1DEVp4pG+K4+B4XkbMn0syZAADLyKYXJoNYM BCYly2zNQcpEYeJ971tuBCa3sW6vUVQ5BIpv3cBuYFgUdp5MvUhVAR+vFDtrm7kpX5Qa uiFY1cwYoE4ZWSkAXJOpSk3AIapY4bWezIi3eKgCOoiTimCDvgvNWFPgc8NbyAszkrjI L4jw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Kw2B6lyk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h20si8632391edw.304.2020.11.09.18.48.51; Mon, 09 Nov 2020 18:49:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Kw2B6lyk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729648AbgKJCr1 (ORCPT + 99 others); Mon, 9 Nov 2020 21:47:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729336AbgKJCr1 (ORCPT ); Mon, 9 Nov 2020 21:47:27 -0500 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10AD8C0613D3 for ; Mon, 9 Nov 2020 18:47:27 -0800 (PST) Received: by mail-pl1-x641.google.com with SMTP id u2so5712349pls.10 for ; Mon, 09 Nov 2020 18:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6UuLx7prIHda8827z12iEWkf6vSvIP09lTJVmS5Ox0Q=; b=Kw2B6lykWnSw7p5AV07ZJWL2A+cDzPdUYe9FzX/Us+etFHFI/T/T661fzpgfpmkB23 L0s3IqzWxMuEpLtG2nf6epBUGvBgNQslbrwL/xWnLHM+dK3GSDrF8rS8Ot0Oc564aJVq 519Wx4Vc34QuvNNgwC7LCzTeN+G1UMlAKa5NF+0slmhYZh6HLDYjufjEZVDPLlIGIQQe VLqdYK/5TswL8tpPoztGNjJ6kb5bI+IoagL3MAll0zOwQtq40+uQ1lh3Pd4g/04WfzRU Ijgf2QTBUMV3h0wJsQ3ydF/lb4a7N9BHcoTppT3suDT0Hqj+oetpijIKCSsBuOfIKIVK ZH/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6UuLx7prIHda8827z12iEWkf6vSvIP09lTJVmS5Ox0Q=; b=Yi2BJh9bW2shoC4VOmruQGnP+/Nf+bFOBZ76lLITB15vsOCDGTghyceG17j95m/1na Po2Ii5j1zX7NBU1MbTgr+vA4FEddV8OBzmHWXG4BvzCd37XnaFXShtLmDf1qTJ3tG+aX FUm3UPg4NQlshZ9zONBp0b+DUpoJeOoPLfJU9L2hw5eEpHh4LlIMOdQzqLRUY+xuiLxM FGXPgtKJQ1UOc2z/ei0aDGgs86UiL9ZSRFgdSKh52xEZHbuGscQikH2h80frZwQjWfbj 7lJzACFM+EE+HrCTayevp1suiPWYNQF38EJMZHC0svpAb0tDk2cGNzvKccGDXXiZ6Yjp DYAg== X-Gm-Message-State: AOAM530SzMV+GHjCBDNPOHAdl9fSCX+ZmOBxaXGTY+jru2Jt2mt8SzW9 15EWA4PxKt+Cj96atSPqDLH2qE5MeP1DDw== X-Received: by 2002:a17:902:d309:b029:d7:cc2d:1ee7 with SMTP id b9-20020a170902d309b02900d7cc2d1ee7mr1676854plc.10.1604976446323; Mon, 09 Nov 2020 18:47:26 -0800 (PST) Received: from localhost ([122.172.12.172]) by smtp.gmail.com with ESMTPSA id i11sm12461961pfq.156.2020.11.09.18.47.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 18:47:25 -0800 (PST) Date: Tue, 10 Nov 2020 08:17:23 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Linux PM , "Rafael J. Wysocki" , Srinivas Pandruvada , Zhang Rui , LKML , Doug Smythies Subject: Re: [PATCH v2 3/4] cpufreq: Add strict_target to struct cpufreq_policy Message-ID: <20201110024723.a5ouawbgj5ftyfe4@vireshk-i7> References: <13269660.K2JYd4sGFX@kreacher> <2826323.52ZM0ncLkd@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2826323.52ZM0ncLkd@kreacher> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09-11-20, 17:53, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Add a new field to be set when the CPUFREQ_GOV_FLAG_STRICT_TARGET > flag is set for the current governor to struct cpufreq_policy, so > that the drivers needing to check CPUFREQ_GOV_FLAG_STRICT_TARGET do > not have to access the governor object during every frequency > transition. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c | 2 ++ > include/linux/cpufreq.h | 6 ++++++ > 2 files changed, 8 insertions(+) > > Index: linux-pm/drivers/cpufreq/cpufreq.c > =================================================================== > --- linux-pm.orig/drivers/cpufreq/cpufreq.c > +++ linux-pm/drivers/cpufreq/cpufreq.c > @@ -2280,6 +2280,8 @@ static int cpufreq_init_governor(struct > } > } > > + policy->strict_target = !!(policy->governor->flags & CPUFREQ_GOV_FLAG_STRICT_TARGET); > + > return 0; > } > > Index: linux-pm/include/linux/cpufreq.h > =================================================================== > --- linux-pm.orig/include/linux/cpufreq.h > +++ linux-pm/include/linux/cpufreq.h > @@ -109,6 +109,12 @@ struct cpufreq_policy { > bool fast_switch_enabled; > > /* > + * Set if the CPUFREQ_GOV_FLAG_STRICT_TARGET flag is set for the > + * current governor. > + */ > + bool strict_target; > + > + /* > * Preferred average time interval between consecutive invocations of > * the driver to set the frequency for this policy. To be set by the > * scaling driver (0, which is the default, means no preference). I was kind of hoping to avoid adding a field here when I proposed updating the gov structure. I do understand the performance related penalty of accessing the gov structure for fast switch case though and so wonder if we really need this, then should we avoid changing the gov structure at all ? I mean there is only one user of that field now, do we really need a flag for it ? We can just do the string comparison here with powersave and performance to set strict_target. Whatever you feel is better though. Acked-by: Viresh Kumar -- viresh