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
next prev parent 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.