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 C51B8EB64DD for ; Tue, 1 Aug 2023 09:47:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233606AbjHAJrR (ORCPT ); Tue, 1 Aug 2023 05:47:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233608AbjHAJqs (ORCPT ); Tue, 1 Aug 2023 05:46:48 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3B9F19AA for ; Tue, 1 Aug 2023 02:45:28 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-4fe2d152f62so4062346e87.0 for ; Tue, 01 Aug 2023 02:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690883127; x=1691487927; 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=wjzE0pMdAWPzb0ytcueVWoMn3QK/GK8CBwvH9LJxWgk=; b=k222fY9P8sD2BkxsXbmTBvfMWrjjvKuo76a0gnS3ewacXTR3lCcEqCO0FkKeoL/3Fy nfuy9byD1ZLK+6waJrMUEJcLvF0CJ6HwNk/n7b5qE1ktFCGw6BbVG8Kf9cEEF5IVwL48 icD8zbt0PR7iGX7F/w+GRFcBoChvQ6tkBfG1tVnjLVvSmCWLI31om1iXvBXT76zxmzbL UJwjvHVmxCCLfVPUGgMXNr+BOWcAjGluz9IiXFo+ykNTVWHUY2OkqFwnIfI9YDAroMfA ylfxYHvUqhf1x6zbPXeciApsWAI8wPOq4EJ2wcStfZwO2EFhD32vyHfqbnWV9GnxyytE QPrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690883127; x=1691487927; 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=wjzE0pMdAWPzb0ytcueVWoMn3QK/GK8CBwvH9LJxWgk=; b=kwhJ9rVIE+Bk7eyiADsZ+oRqOKxICqQ/DjkLil+Bk/1r7/PXkhWHjGuVI7Ppn2RReZ bOU2g4FdvOm9b3/8wnTVhZ8JfngrmgMn/bymnI75x+pm4sHx6ub0/X1Uujyws5+zE05j qqwRc03DsTMweelvPq3jJXxLcrSYnulEdZFGwNnA3C1+h5oY+wqqd/Qjs4saqEMNYYyz Z93Th72PgzlCx8HIzHLPR2PLhoIkcKNwPnjGvIjMoSiuxTCkVeFXP8nhtKTpWAZmEDud b3taBw19XPmSE2jWeu5QT5860B73oIcj7s4HsQbDbSC5/ytsIJnrk501nAACoSbQyO2F Hwow== X-Gm-Message-State: ABy/qLbW/nzegbBXPZ1T4nGU4xrUEurYVEeRLj+ukxxjhxZ3VkxphKFX NT0Ve/TY1HozS2MyINhR+vnqjg== X-Google-Smtp-Source: APBJJlFjBOyeZWNZUk3UMzFzo9zb7KYygtaPteVYSbVoNDekf1oBQgNfLV5BFrAcxoqViRRR1BWgGg== X-Received: by 2002:a05:6512:290:b0:4fe:ee7:a32a with SMTP id j16-20020a056512029000b004fe0ee7a32amr1816148lfp.16.1690883126707; Tue, 01 Aug 2023 02:45:26 -0700 (PDT) Received: from google.com (64.227.90.34.bc.googleusercontent.com. [34.90.227.64]) by smtp.gmail.com with ESMTPSA id q1-20020a056402040100b005222a38c7b2sm6754243edv.48.2023.08.01.02.45.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 02:45:26 -0700 (PDT) Date: Tue, 1 Aug 2023 09:45:22 +0000 From: Quentin Perret To: David Dai Cc: "Rafael J. Wysocki" , Viresh Kumar , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sudeep Holla , Saravana Kannan , Masami Hiramatsu , Will Deacon , Peter Zijlstra , Vincent Guittot , Marc Zyngier , Oliver Upton , Dietmar Eggemann , Pavan Kondeti , Gupta Pankaj , Mel Gorman , kernel-team@android.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/2] cpufreq: add virtual-cpufreq driver Message-ID: References: <20230731174613.4133167-1-davidai@google.com> <20230731174613.4133167-3-davidai@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230731174613.4133167-3-davidai@google.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi David, On Monday 31 Jul 2023 at 10:46:09 (-0700), David Dai wrote: > +static unsigned int virt_cpufreq_set_perf(struct cpufreq_policy *policy) > +{ > + struct virt_cpufreq_drv_data *data = policy->driver_data; > + /* > + * Use cached frequency to avoid rounding to freq table entries > + * and undo 25% frequency boost applied by schedutil. > + */ The VMM would be a better place for this scaling I think, the driver can't/shouldn't make assumptions about the governor it is running with given that this is a guest userspace decision essentially. IIRC the fast_switch() path is only used by schedutil, so one could probably make a case to scale things there, but it'd be inconsistent with the "slow" switch case, and would create a fragile dependency, so it's probably not worth pursuing. > + u32 freq = mult_frac(policy->cached_target_freq, 80, 100); > + > + data->ops->set_freq(policy, freq); > + return 0; > +} Thanks, Quentin