All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Beata Michalska <beata.michalska@arm.com>
To: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com,
	vanshikonda@os.amperecomputing.com
Cc: 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: [PATCH v4 0/4] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu
Date: Fri,  5 Apr 2024 14:33:15 +0100	[thread overview]
Message-ID: <20240405133319.859813-1-beata.michalska@arm.com> (raw)

Introducing arm64 specific version of arch_freq_get_on_cpu, cashing on
existing implementation for FIE and AMUv1 support: the frequency scale
factor, updated on each sched tick, serves as a base for retrieving
the frequency for a given CPU, representing an average frequency
reported between the ticks - thus its accuracy is limited.

The changes have been rather lightly (due to some limitations) tested on
an FVP model. Note that some small discrepancies have been observed while
testing (on the model) and this is currently being investigated, though it
should not have any significant impact on the overall results.

Relevant discussions:
[1] https://lore.kernel.org/all/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/
[2] https://lore.kernel.org/all/7eozim2xnepacnnkzxlbx34hib4otycnbn4dqymfziqou5lw5u@5xzpv3t7sxo3/
[3] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
[4] https://lore.kernel.org/lkml/ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com/T/#m4e74cb5a0aaa353c60fedc6cfb95ab7a6e381e3c

v4:
- dropping seqcount
- fixing identifying active cpu within given policy
- skipping full dynticks cpus when retrieving the freq
- bringing back plugging in arch_freq_get_on_cpu into cpuinfo_cur_freq

v3:
- dropping changes to cpufreq_verify_current_freq
- pulling in changes from Ionela initializing capacity_freq_ref to 0
  (thanks for that!)  and applying suggestions made by her during last review:
	- switching to arch_scale_freq_capacity and arch_scale_freq_ref when
	  reversing freq scale factor computation
	- swapping shift with multiplication
- adding time limit for considering last scale update as valid
- updating frequency scale factor upon entering idle

v2:
- Splitting the patches
- Adding comment for full dyntick mode
- Plugging arch_freq_get_on_cpu into cpufreq_verify_current_freq instead
  of in show_cpuinfo_cur_freq to allow the framework to stay more in sync
  with potential freq changes


Beata Michalska (3):
  arm64: Provide an AMU-based version of arch_freq_get_on_cpu
  arm64: Update AMU-based frequency scale factor on entering idle
  cpufreq: Use arch specific feedback for cpuinfo_cur_freq

Ionela Voinescu (1):
  arch_topology: init capacity_freq_ref to 0

 arch/arm64/kernel/topology.c | 125 ++++++++++++++++++++++++++++++++---
 drivers/base/arch_topology.c |   8 ++-
 drivers/cpufreq/cpufreq.c    |   4 +-
 3 files changed, 123 insertions(+), 14 deletions(-)

-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Beata Michalska <beata.michalska@arm.com>
To: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, ionela.voinescu@arm.com,
	vanshikonda@os.amperecomputing.com
Cc: 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: [PATCH v4 0/4] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu
Date: Fri,  5 Apr 2024 14:33:15 +0100	[thread overview]
Message-ID: <20240405133319.859813-1-beata.michalska@arm.com> (raw)

Introducing arm64 specific version of arch_freq_get_on_cpu, cashing on
existing implementation for FIE and AMUv1 support: the frequency scale
factor, updated on each sched tick, serves as a base for retrieving
the frequency for a given CPU, representing an average frequency
reported between the ticks - thus its accuracy is limited.

The changes have been rather lightly (due to some limitations) tested on
an FVP model. Note that some small discrepancies have been observed while
testing (on the model) and this is currently being investigated, though it
should not have any significant impact on the overall results.

Relevant discussions:
[1] https://lore.kernel.org/all/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/
[2] https://lore.kernel.org/all/7eozim2xnepacnnkzxlbx34hib4otycnbn4dqymfziqou5lw5u@5xzpv3t7sxo3/
[3] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
[4] https://lore.kernel.org/lkml/ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com/T/#m4e74cb5a0aaa353c60fedc6cfb95ab7a6e381e3c

v4:
- dropping seqcount
- fixing identifying active cpu within given policy
- skipping full dynticks cpus when retrieving the freq
- bringing back plugging in arch_freq_get_on_cpu into cpuinfo_cur_freq

v3:
- dropping changes to cpufreq_verify_current_freq
- pulling in changes from Ionela initializing capacity_freq_ref to 0
  (thanks for that!)  and applying suggestions made by her during last review:
	- switching to arch_scale_freq_capacity and arch_scale_freq_ref when
	  reversing freq scale factor computation
	- swapping shift with multiplication
- adding time limit for considering last scale update as valid
- updating frequency scale factor upon entering idle

v2:
- Splitting the patches
- Adding comment for full dyntick mode
- Plugging arch_freq_get_on_cpu into cpufreq_verify_current_freq instead
  of in show_cpuinfo_cur_freq to allow the framework to stay more in sync
  with potential freq changes


Beata Michalska (3):
  arm64: Provide an AMU-based version of arch_freq_get_on_cpu
  arm64: Update AMU-based frequency scale factor on entering idle
  cpufreq: Use arch specific feedback for cpuinfo_cur_freq

Ionela Voinescu (1):
  arch_topology: init capacity_freq_ref to 0

 arch/arm64/kernel/topology.c | 125 ++++++++++++++++++++++++++++++++---
 drivers/base/arch_topology.c |   8 ++-
 drivers/cpufreq/cpufreq.c    |   4 +-
 3 files changed, 123 insertions(+), 14 deletions(-)

-- 
2.25.1


_______________________________________________
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-05 13:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 13:33 Beata Michalska [this message]
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 ` [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
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

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=20240405133319.859813-1-beata.michalska@arm.com \
    --to=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=vanshikonda@os.amperecomputing.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.