All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beata Michalska <beata.michalska@arm.com>
To: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>,
	viresh.kumar@linaro.org
Cc: Sumit Gupta <sumitg@nvidia.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	ionela.voinescu@arm.com, sudeep.holla@arm.com, will@kernel.org,
	catalin.marinas@arm.com, rafael@kernel.org,
	viresh.kumar@linaro.org, yang@os.amperecomputing.com,
	lihuisong@huawei.com, zhanjie9@hisilicon.com,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Bibek Basu <bbasu@nvidia.com>
Subject: Re: [PATCH v7 3/4] arm64: Provide an AMU-based version of arch_freq_avg_get_on_cpu
Date: Thu, 10 Oct 2024 13:08:23 +0200	[thread overview]
Message-ID: <Zwe1p0La_AFknglf@arm.com> (raw)
In-Reply-To: <5y3yz2ct2o42c53dc6rwpse3andstjx74lowt2b3hohj4ogbct@nu2szdnxvxid>

On Thu, Oct 03, 2024 at 02:54:22PM -0700, Vanshidhar Konda wrote:
> On Thu, Oct 03, 2024 at 11:39:54PM GMT, Beata Michalska wrote:
> > On Thu, Sep 26, 2024 at 04:21:14PM -0700, Vanshidhar Konda wrote:
> > > On Thu, Sep 26, 2024 at 12:34:01PM GMT, Beata Michalska wrote:
> > > > On Tue, Sep 17, 2024 at 05:41:09PM +0530, Sumit Gupta wrote:
> > > > > Hi Beata,
> > > > Hi Sumit,
> > > > >
> > > > > Thank you for the patches.
> > > > Thank you for having a look at those.
> > > > >
> > > > > On 13/09/24 18:59, Beata Michalska wrote:
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > With the Frequency Invariance Engine (FIE) being already wired up with
> > > > > > sched tick and making use of relevant (core counter and constant
> > > > > > counter) AMU counters, getting the average frequency for a given CPU,
> > > > > > can be achieved by utilizing the frequency scale factor which reflects
> > > > > > an average CPU frequency for the last tick period length.
> > > > > >
> > > > > > The solution is partially based on APERF/MPERF implementation of
> > > > > > arch_freq_get_on_cpu.
> > > > > >
> > > > > > Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com>
> > > > > > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > > > > > ---
> > > > > >   arch/arm64/kernel/topology.c | 109 +++++++++++++++++++++++++++++++----
> > > > > >   1 file changed, 99 insertions(+), 10 deletions(-)
> > > > > >
> 
> --- snip ----
> 
> > > > >
> > > > >     ..
> > > > >   freq_comput:
> > > > >     scale = arch_scale_freq_capacity(cpu);
> > > > >     freq = scale * arch_scale_freq_ref(cpu);
> > > > >   ----
> > > > >
> > > > This boils down to the question what that function, and the information it
> > > > provides, represent really. The 'unknown' here simply says the CPU has been idle
> > > > for a while and as such the frequency data is a bit stale and it does not
> > > > represent the average freq the CPU is actually running at anymore, which is
> > > > the intention here really. Or, that the given CPU is a non-housekeeping one.
> > > > Either way I believe this is a useful information, instead of providing
> > > > stale data with no indication on whether the frequency is really the 'current'
> > > > one or not.
> > > >
> > > > If that is somehow undesirable we can discuss this further, though I'd rather
> > > > avoid exposing an interface where the feedback provided is open to
> > > > interpretation at all times.
> > > 
> > > Would it make sense to identify that the frequency reporting is unknown due to
> > > cpu being idle vs some other issue like being a non-housekeeping CPU? Would
> > > returning a value of 0 make it easier for tools to represent that the CPU is
> > > currently idle?
> > That is an option.
> > Another one would be to return an error for those cases. This would make it
> > easier to distinguish between valid frequency &/| idle CPU vs tickless CPU
> > (EINVAL vs ENOENT) ?
> > 
> 
> That seems like a good idea but I suspect it would be confusing to the end user.
> 
> If a user runs `cat /sys/devices/system/cpu/cpu2/cpuinfo_avg_freq` they would
> get an error in some cases or get a number in some other iterations.
>
That is a fair point but I am not entirely convinced using '0' instead makes
things any more clearer as this is in no way a valid CPU frequency.
As long as we document the expected behaviour keeping the interface well
defined,  both options should be fine I guess.

@Viresh: what is your opinion on that one ?

---
BR
Beata
> Thanks,
> Vanshidhar
> 
> > ---
> > BR
> > Beata
> > > 
> > > Thanks,
> > > Vanshidhar
> > > 
> > > >
> > > > ---
> > > > Best Regards
> > > > Beata
> > > > > Thank you,
> > > > > Sumit Gupta
> > > > >
> > > > > P.S. Will be on afk for next 2 weeks with no access to email. Please expect
> > > > > a delay in response.
> > > > >
> > > > > > +               cpu = ref_cpu;
> > > > > > +               goto retry;
> > > > > > +       }
> > > > > > +       /*
> > > > > > +        * Reversed computation to the one used to determine
> > > > > > +        * the arch_freq_scale value
> > > > > > +        * (see amu_scale_freq_tick for details)
> > > > > > +        */
> > > > > > +       scale = arch_scale_freq_capacity(cpu);
> > > > > > +       freq = scale * arch_scale_freq_ref(cpu);
> > > > > > +       freq >>= SCHED_CAPACITY_SHIFT;
> > > > > > +       return freq;
> > > > > > +}
> > > > > > +
> > > > >
> > > > > >   static void amu_fie_setup(const struct cpumask *cpus)
> > > > > >   {
> > > > > >          int cpu;
> > > > > > --
> > > > > > 2.25.1
> > > > > >

  reply	other threads:[~2024-10-10 11:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-13 13:29 [PATCH v7 0/4] Add support for AArch64 AMUv1-based average freq Beata Michalska
2024-09-13 13:29 ` [PATCH v7 1/4] cpufreq: Introduce an optional cpuinfo_avg_freq sysfs entry Beata Michalska
2024-09-25  8:58   ` Jie Zhan
2024-09-26 10:42     ` Beata Michalska
2024-10-29  7:04   ` Viresh Kumar
2024-10-29 11:31     ` Rafael J. Wysocki
2024-11-04  8:01       ` Beata Michalska
2024-11-04 13:26         ` Rafael J. Wysocki
2024-11-04  8:00     ` Beata Michalska
2024-11-08  6:28       ` Viresh Kumar
2024-09-13 13:29 ` [PATCH v7 2/4] arm64: amu: Delay allocating cpumask for AMU FIE support Beata Michalska
2024-09-13 13:29 ` [PATCH v7 3/4] arm64: Provide an AMU-based version of arch_freq_avg_get_on_cpu Beata Michalska
2024-09-17 12:11   ` Sumit Gupta
2024-09-26 10:34     ` Beata Michalska
2024-09-26 23:21       ` Vanshidhar Konda
2024-10-03 21:39         ` Beata Michalska
2024-10-03 21:54           ` Vanshidhar Konda
2024-10-10 11:08             ` Beata Michalska [this message]
2024-10-11 16:29               ` Vanshidhar Konda
2024-10-14 17:46                 ` Sumit Gupta
2024-10-16 20:45                   ` Beata Michalska
2024-10-29  6:53               ` Viresh Kumar
2024-11-04  7:58                 ` Beata Michalska
2024-09-13 13:29 ` [PATCH v7 4/4] arm64: Update AMU-based freq scale factor on entering idle Beata Michalska
2024-10-16 10:59 ` [PATCH v7 0/4] Add support for AArch64 AMUv1-based average freq Catalin Marinas
2024-10-16 20:51   ` Beata Michalska
2024-10-27 18:16     ` 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=Zwe1p0La_AFknglf@arm.com \
    --to=beata.michalska@arm.com \
    --cc=bbasu@nvidia.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=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=sumitg@nvidia.com \
    --cc=vanshikonda@os.amperecomputing.com \
    --cc=viresh.kumar@linaro.org \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    --cc=zhanjie9@hisilicon.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.