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 96905C04FDF for ; Tue, 1 Aug 2023 09:47:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233358AbjHAJrT (ORCPT ); Tue, 1 Aug 2023 05:47:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233600AbjHAJqs (ORCPT ); Tue, 1 Aug 2023 05:46:48 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBD4B19A8 for ; Tue, 1 Aug 2023 02:45:28 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4fe07f0636bso8829879e87.1 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=fZkGTiX/BAE+9BqYhKTDircWOOPXcgE0choLezPmakbk5NtciD30xJ/LrQfDZdxlMT +iJHIfdmrkNx8jKzERojALYCM6GRE3vlIIzMSNn8Eb3MvvEIk7OcESVn+H7s1BvGXQiY tymkWtzx1uOIKXIAvucFG8D9BEbeOI23eU/5MDtBfPNa23oxTL6xdKWXM7nES1oR5+zV XY9aJtVFzL6L+FoY1/+2crCIS05UJSHP2OIMvvbMLdtuG1FDOu2Af+xCRAjJonnnuxlR Fx3q0HEcFDMZ3/CyV2u4Ie5E+147eTe2lt5TEpPlw7FxT2ZJiNbfIr8bqkATV2tDXeiv Purg== X-Gm-Message-State: ABy/qLZLgCb2CQfLo5WiWgZ4Boz/BOV0d5Ggdu/LIOm48X0bcCw7+lgn QpGOqyqa9DFLjYtsTuOsjLg5XA== 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: linux-kernel@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