linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Beata Michalska <beata.michalska@arm.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com,
	will@kernel.org, catalin.marinas@arm.com, sfr@canb.auug.org.au,
	ionela.voinescu@arm.com, linux-next@vger.kernel.org,
	sumitg@nvidia.com, yang@os.amperecomputing.com,
	vanshikonda@os.amperecomputing.com, lihuisong@huawei.com,
	zhanjie9@hisilicon.com, ptsm@linux.microsoft.com
Subject: Re: [PATCH] arm64: Utilize for_each_cpu_wrap for reference lookup
Date: Wed, 19 Feb 2025 09:19:56 +0100	[thread overview]
Message-ID: <Z7WULBZPsh8QK3DV@arm.com> (raw)
In-Reply-To: <Z7TqFLU0Kwg9cUjO@thinkpad>

On Tue, Feb 18, 2025 at 03:14:23PM -0500, Yury Norov wrote:
> On Tue, Feb 18, 2025 at 07:24:12PM +0000, Beata Michalska wrote:
> > While searching for a reference CPU within a given policy,
> > arch_freq_get_on_cpu relies on cpumask_next_wrap to iterate over
> > all available CPUs and to ensure each is verified only once.
> > Recent changes to cpumask_next_wrap will handle the latter no more,
> > so switching to for_each_cpu_wrap, which  preserves expected behavior
> > while ensuring compatibility with the updates.
> 
> This is technically correct, but I would rather point that for
> iterating over each CPU, it's better to use a dedicated iterator
> instead of opencoded loop.

I can certainly add that.
> 
> > Fixes: 16d1e27475f6 ("arm64: Provide an AMU-based version of arch_freq_get_on_cpu")
> > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > ---
> >  based on arm64 for-next/amuv1-avg-freq
> > 
> >  arch/arm64/kernel/topology.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index a09b0551ec59..9e3583720668 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -254,7 +254,7 @@ int arch_freq_get_on_cpu(int cpu)
> >  		if (!housekeeping_cpu(cpu, HK_TYPE_TICK) ||
> >  		    time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
> >  			struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> > -			int ref_cpu = cpu;
> > +			int ref_cpu;
> >  
> >  			if (!policy)
> >  				return -EINVAL;
> > @@ -265,11 +265,15 @@ int arch_freq_get_on_cpu(int cpu)
> >  				return -EOPNOTSUPP;
> >  			}
> >  
> > -			do {
> > -				ref_cpu = cpumask_next_wrap(ref_cpu, policy->cpus,
> > -							    start_cpu, true);
> > -
> > -			} while (ref_cpu < nr_cpu_ids && idle_cpu(ref_cpu));
> > +			for_each_cpu_wrap(ref_cpu, policy->cpus, cpu + 1) {
> > +				if (ref_cpu == start_cpu) {
> > +					/* Prevent verifying same CPU twice */
> > +					ref_cpu = nr_cpu_ids;
> > +					break;
> 
> If start_cpu == cpu, and you begin with 'cpu + 1', you will never
> check the 'cpu' for idle, right? Maybe like this?
> 
>         unsigned int start_cpu = cpu + 1;
> 
This is not entirely a pure for-each case here.
If this loop is reached, it means the start_cpu did not meet the criteria, and
we are trying to find another CPU within the policy that might. Which is why we
pick up the next in line and check whether it is suitable or not.
Testing for idle is just a shortcut, as an idle CPU will most probably not be
considered a good reference either way.

---
BR
Beata
> > +				}
> > +				if (!idle_cpu(ref_cpu))
> > +					break;
> > +			}
> >  
> >  			cpufreq_cpu_put(policy);
> >  
> > -- 
> > 2.25.1


      reply	other threads:[~2025-02-19  8:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 19:24 [PATCH] arm64: Utilize for_each_cpu_wrap for reference lookup Beata Michalska
2025-02-18 20:14 ` Yury Norov
2025-02-19  8:19   ` Beata Michalska [this message]

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=Z7WULBZPsh8QK3DV@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=linux-next@vger.kernel.org \
    --cc=ptsm@linux.microsoft.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sudeep.holla@arm.com \
    --cc=sumitg@nvidia.com \
    --cc=vanshikonda@os.amperecomputing.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    --cc=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).