[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Penny, Zheng" <penny.zheng@xxxxxxx>
  • Date: Wed, 2 Jul 2025 09:49:15 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wzEJRhehm/z3LJvdVMH0Nmp4JL5zzZ4HbQBK9oZZyzU=; b=aT+81slwC6IimnVXhgM5zV6GjfGp8LgsKUCVujOzHNJDFx56/z4WScGR7HlOvkAL+Ezza/5jNdesbVkYRwkH/ve1RcdDSdxWbGyBrXIlnGfWpwK/aKZczvs+2pujyrlCoqI/bPgnQHQnlS1f7bi7/TY1G6G4ydEL++8sNcmHR7M07j4htZ2yviBNB8opiF1TBlst+Yx3d6UkUDB1D+n9oQe7/bEzpma1o/pC2U9iMHH4sHcZjWvx1lvovNvfIpVDzP8rtnyx4yWmw55a2Nv3etHiwQndPdoB3k3Gtftarr1l2EryCRJqXeE5Fri3ggXLpNXD0e0H3OqrUym0D32YuA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oU5bSG2tDwTLQpLjHpmpNikF1rYFjOgXhLnjQQOtxSazQ4jJfeNoTull4d9OnQXxb3nbQWWP4zoHaIqdZUmXwcMJv3PmOlQfjNSNUgY5H2pVoM7HKg3exozYCCGeO1Ie8ON5GfFYJ+mhUruBWj9IaIXHhHXSpzgw5GlIe1DicDqLnA2EuUzUr39EJi2+SQ0N2up9tnKXXQLFNHV9vkX4KFefJHJl+3fWvKFNmMhZYMG/QU6jIAsNUYqYysTKPO+2RZnRVPrkDM7dkq/y9yKYgt7TzPLTka74nGKjAoXwTgLNPzF1UTf1QxPXCkj+7xDACYEDwS1aZ/b2yob4Rqb5Zw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 02 Jul 2025 09:49:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-07-02T09:00:04.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
  • Thread-index: AQHbzuRFzooSbGuOOkWtJb1ZJ/MIx7QGEZYAgBiv97A=
  • Thread-topic: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for cpufreq scaling

[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Tuesday, June 17, 2025 12:00 AM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v5 10/18] xen/cpufreq: introduce a new amd cppc driver for
> cpufreq scaling
>
> On 27.05.2025 10:48, Penny Zheng wrote:
> > --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> > +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> > +        /*
> > +         * We don't need to convert to kHz for computing offset and can
> > +         * directly use nominal_mhz and lowest_mhz as the division
> > +         * will remove the frequency unit.
> > +         */
> > +        offset = data->caps.nominal_perf -
> > +                 (mul * cppc_data->cpc.nominal_mhz) / div;
> > +    }
> > +    else
> > +    {
> > +        /* Read Processor Max Speed(MHz) as anchor point */
> > +        mul = data->caps.highest_perf;
> > +        div = this_cpu(pxfreq_mhz);
> > +        if ( !div )
> > +            return -EINVAL;
>
> What's wrong about the function arguments in this case? (Same question again 
> on
> further uses of EINVAL below.)
>

If we could not get processor max frequency, the whole function is useless...
Maybe -EOPNOTSUPP is more suitable than -EINVAL;

> > +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
> > +                                            unsigned int target_freq,
> > +                                            unsigned int relation) {
> > +    unsigned int cpu = policy->cpu;
> > +    const struct amd_cppc_drv_data *data = per_cpu(amd_cppc_drv_data, cpu);
> > +    uint8_t des_perf;
> > +    int res;
> > +
> > +    if ( unlikely(!target_freq) )
> > +        return 0;
> > +
> > +    res = amd_cppc_khz_to_perf(data, target_freq, &des_perf);
> > +    if ( res )
> > +        return res;
> > +
> > +    /*
> > +     * Setting with "lowest_nonlinear_perf" to ensure governoring
> > +     * performance in P-state range.
> > +     */
> > +    amd_cppc_write_request(policy->cpu, data->caps.lowest_nonlinear_perf,
> > +                           des_perf, data->caps.highest_perf);
>
> I fear I don't understand the comment, and hence it remains unclear to me why
> lowest_nonlinear_perf is being used here.
>

How about
```
Choose lowest nonlinear performance as the minimum performance level at which 
the platform may run.
Lowest nonlinear performance is the lowest performance level at which nonlinear 
power savings are achieved,
Above this threshold, lower performance levels should be generally more energy 
efficient than higher performance levels.
```
>
> Jan

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.