All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
To: Beata Michalska <beata.michalska@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,  ionela.voinescu@arm.com,
	sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com,
	 vincent.guittot@linaro.org, sumitg@nvidia.com,
	yang@os.amperecomputing.com,  lihuisong@huawei.com
Subject: Re: [PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq
Date: Mon, 15 Apr 2024 21:23:10 -0700	[thread overview]
Message-ID: <76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd> (raw)
In-Reply-To: <20240405133319.859813-5-beata.michalska@arm.com>

On Fri, Apr 05, 2024 at 02:33:19PM +0100, Beata Michalska wrote:
>Some architectures provide a way to determine an average frequency over
>a certain period of time based on available performance monitors (AMU on
>ARM or APERF/MPERf on x86). With those at hand, enroll arch_freq_get_on_cpu
>into cpuinfo_cur_freq policy sysfs attribute handler, which is expected to
>represent the current frequency of a given CPU, as obtained by the hardware.
>This is the type of feedback that counters do provide.
>

--- snip ---

While testing this patch series on AmpereOne system, I simulated CPU
frequency throttling when the system is under power or thermal
constraints.

In this scenario, based on the user guilde, I expect scaling_cur_freq
is the frequency the kernel requests from the hardware; cpuinfo_cur_freq
is the actual frequency that the hardware is able to run at during the
power or thermal constraints.

The AmpereOne system I'm testing on has the following configuration:
- Max frequency is 3000000
- Support for AMU registers
- ACPI CPPC feedback counters use PCC register space
- Fedora 39 with 6.7.5 kernel
- Fedora 39 with 6.9.0-rc3 + this patch series

With 6.7.5 kernel:
Core        scaling_cur_freq        cpuinfo_cur_freq
----        ----------------        ----------------
0             3000000                 2593000
1             3000000                 2613000
2             3000000                 2625000
3             3000000                 2632000

With 6.9.0-rc3 + this patch series:
Core        scaling_cur_freq        cpuinfo_cur_freq
----        ----------------        ----------------
0             2671875                 2671875
1             2589632                 2589632
2             2648437                 2648437
3             2698242                 2698242

In the second case we can't identify that the CPU frequency is
being throttled by the hardware. I noticed this behavior with
or without this patch.

Thanks,
Vanshi

WARNING: multiple messages have this Message-ID (diff)
From: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
To: Beata Michalska <beata.michalska@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,  ionela.voinescu@arm.com,
	sudeep.holla@arm.com, will@kernel.org, catalin.marinas@arm.com,
	 vincent.guittot@linaro.org, sumitg@nvidia.com,
	yang@os.amperecomputing.com,  lihuisong@huawei.com
Subject: Re: [PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq
Date: Mon, 15 Apr 2024 21:23:10 -0700	[thread overview]
Message-ID: <76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd> (raw)
In-Reply-To: <20240405133319.859813-5-beata.michalska@arm.com>

On Fri, Apr 05, 2024 at 02:33:19PM +0100, Beata Michalska wrote:
>Some architectures provide a way to determine an average frequency over
>a certain period of time based on available performance monitors (AMU on
>ARM or APERF/MPERf on x86). With those at hand, enroll arch_freq_get_on_cpu
>into cpuinfo_cur_freq policy sysfs attribute handler, which is expected to
>represent the current frequency of a given CPU, as obtained by the hardware.
>This is the type of feedback that counters do provide.
>

--- snip ---

While testing this patch series on AmpereOne system, I simulated CPU
frequency throttling when the system is under power or thermal
constraints.

In this scenario, based on the user guilde, I expect scaling_cur_freq
is the frequency the kernel requests from the hardware; cpuinfo_cur_freq
is the actual frequency that the hardware is able to run at during the
power or thermal constraints.

The AmpereOne system I'm testing on has the following configuration:
- Max frequency is 3000000
- Support for AMU registers
- ACPI CPPC feedback counters use PCC register space
- Fedora 39 with 6.7.5 kernel
- Fedora 39 with 6.9.0-rc3 + this patch series

With 6.7.5 kernel:
Core        scaling_cur_freq        cpuinfo_cur_freq
----        ----------------        ----------------
0             3000000                 2593000
1             3000000                 2613000
2             3000000                 2625000
3             3000000                 2632000

With 6.9.0-rc3 + this patch series:
Core        scaling_cur_freq        cpuinfo_cur_freq
----        ----------------        ----------------
0             2671875                 2671875
1             2589632                 2589632
2             2648437                 2648437
3             2698242                 2698242

In the second case we can't identify that the CPU frequency is
being throttled by the hardware. I noticed this behavior with
or without this patch.

Thanks,
Vanshi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-04-16  4:23 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 13:33 [PATCH v4 0/4] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu Beata Michalska
2024-04-05 13:33 ` Beata Michalska
2024-04-05 13:33 ` [PATCH v4 1/4] arch_topology: init capacity_freq_ref to 0 Beata Michalska
2024-04-05 13:33   ` Beata Michalska
2024-04-08  8:35   ` Vincent Guittot
2024-04-08  8:35     ` Vincent Guittot
2024-04-05 13:33 ` [PATCH v4 2/4] arm64: Provide an AMU-based version of arch_freq_get_on_cpu Beata Michalska
2024-04-05 13:33   ` Beata Michalska
2024-04-05 13:33 ` [PATCH v4 3/4] arm64: Update AMU-based frequency scale factor on entering idle Beata Michalska
2024-04-05 13:33   ` Beata Michalska
2024-04-10 18:57   ` Sumit Gupta
2024-04-10 18:57     ` Sumit Gupta
2024-04-11 19:30     ` Beata Michalska
2024-04-11 19:30       ` Beata Michalska
2024-04-05 13:33 ` [PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq Beata Michalska
2024-04-05 13:33   ` Beata Michalska
2024-04-16  4:23   ` Vanshidhar Konda [this message]
2024-04-16  4:23     ` Vanshidhar Konda
2024-04-16 15:46     ` Beata Michalska
2024-04-16 15:46       ` Beata Michalska
2024-04-17 21:38       ` Vanshidhar Konda
2024-04-17 21:38         ` Vanshidhar Konda
2024-04-26 10:45         ` Beata Michalska
2024-04-26 10:45           ` Beata Michalska
2024-04-29  9:25           ` Viresh Kumar
2024-04-29  9:25             ` Viresh Kumar
2024-05-01 14:46             ` Vanshidhar Konda
2024-05-01 14:46               ` Vanshidhar Konda
2024-05-07  8:31             ` Beata Michalska
2024-05-07  8:31               ` Beata Michalska
2024-05-07 10:02               ` Beata Michalska
2024-05-07 10:02                 ` Beata Michalska
2024-05-20  9:18                 ` Viresh Kumar
2024-05-20  9:18                   ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76zutrz47zs6i2cquvjo2qn7myxpq7e3c6alhper7n3wrkhf5h@22l5t5pio2cd \
    --to=vanshikonda@os.amperecomputing.com \
    --cc=beata.michalska@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=lihuisong@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=sumitg@nvidia.com \
    --cc=vincent.guittot@linaro.org \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.