From: Ming Lei <ming.lei@redhat.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Breno Leitao <leitao@debian.org>,
Nathan Chancellor <nathan@kernel.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Zi Yan <ziy@nvidia.com>,
ming.lei@redhat.com
Subject: Re: [PATCH 4/9] lib/group_cpus: optimize outer loop in grp_spread_init_one()
Date: Sat, 20 Jan 2024 14:17:38 +0800 [thread overview]
Message-ID: <ZatlggW/8SH6od9O@fedora> (raw)
In-Reply-To: <ZatDXvhvt0mLTi2m@fedora>
On Sat, Jan 20, 2024 at 11:51:58AM +0800, Ming Lei wrote:
> On Fri, Jan 19, 2024 at 06:50:48PM -0800, Yury Norov wrote:
> > Similarly to the inner loop, in the outer loop we can use for_each_cpu()
> > macro, and skip CPUs that have been moved.
> >
> > With this patch, the function becomes O(1), despite that it's a
> > double-loop.
> >
> > While here, add a comment why we can't merge outer logic into the inner
> > loop.
> >
> > Signed-off-by: Yury Norov <yury.norov@gmail.com>
> > ---
> > lib/group_cpus.c | 14 ++++++++------
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/group_cpus.c b/lib/group_cpus.c
> > index 0a8ac7cb1a5d..952aac9eaa81 100644
> > --- a/lib/group_cpus.c
> > +++ b/lib/group_cpus.c
> > @@ -17,16 +17,17 @@ static void grp_spread_init_one(struct cpumask *irqmsk, struct cpumask *nmsk,
> > const struct cpumask *siblmsk;
> > int cpu, sibl;
> >
> > - for ( ; cpus_per_grp > 0; ) {
> > - cpu = cpumask_first(nmsk);
> > -
> > - /* Should not happen, but I'm too lazy to think about it */
> > - if (cpu >= nr_cpu_ids)
> > + for_each_cpu(cpu, nmsk) {
> > + if (cpus_per_grp-- == 0)
> > return;
> >
> > + /*
> > + * If a caller wants to spread IRQa on offline CPUs, we need to
> > + * take care of it explicitly because those offline CPUS are not
> > + * included in siblings cpumask.
> > + */
> > __cpumask_clear_cpu(cpu, nmsk);
> > __cpumask_set_cpu(cpu, irqmsk);
> > - cpus_per_grp--;
> >
> > /* If the cpu has siblings, use them first */
> > siblmsk = topology_sibling_cpumask(cpu);
> > @@ -38,6 +39,7 @@ static void grp_spread_init_one(struct cpumask *irqmsk, struct cpumask *nmsk,
> >
> > __cpumask_clear_cpu(sibl, nmsk);
> > __cpumask_set_cpu(sibl, irqmsk);
> > + cpu = sibl + 1;
>
> It has been tricky enough to update condition variable of for_each_cpu()
> (such kind of pattern can't build in Rust at all), and the above line could
> be more tricky actually.
Not only the above line is tricky, but also it is wrong, because 'cpu'
local variable should always point to the 1st bit in 'nmsk'. However, if
you set it to 'sibl + 1', some bits in 'nmsk' are skipped in the loop,
aren't they?
Thanks,
Ming
next prev parent reply other threads:[~2024-01-20 6:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 2:50 [PATCH v5 0/9] lib/group_cpus: rework grp_spread_init_one() and make it O(1) Yury Norov
2024-01-20 2:50 ` [PATCH 1/9] cpumask: introduce for_each_cpu_and_from() Yury Norov
2024-01-20 3:03 ` Ming Lei
2024-01-21 19:50 ` Yury Norov
2024-01-22 2:41 ` Ming Lei
2024-01-20 2:50 ` [PATCH 2/9] lib/group_cpus: optimize inner loop in grp_spread_init_one() Yury Norov
2024-01-20 3:17 ` Ming Lei
2024-01-20 7:03 ` Ming Lei
2024-01-20 2:50 ` [PATCH 3/9] lib/group_cpus: relax atomicity requirement " Yury Norov
2024-01-20 2:50 ` [PATCH 4/9] lib/group_cpus: optimize outer loop " Yury Norov
2024-01-20 3:51 ` Ming Lei
2024-01-20 6:17 ` Ming Lei [this message]
2024-01-20 2:50 ` [PATCH 5/9] lib/group_cpus: don't zero cpumasks in group_cpus_evenly() on allocation Yury Norov
2024-01-20 2:50 ` [PATCH 6/9] lib/group_cpus: drop unneeded cpumask_empty() call in __group_cpus_evenly() Yury Norov
2024-01-20 2:50 ` [PATCH 7/9] cpumask: define cleanup function for cpumasks Yury Norov
2024-01-20 2:50 ` [PATCH 8/9] lib/group_cpus: rework group_cpus_evenly() Yury Norov
2024-01-20 2:50 ` [PATCH 9/9] lib/group_cpus: simplify group_cpus_evenly() for more Yury Norov
-- strict thread matches above, loose matches on Subject: below --
2023-12-28 20:09 [PATCH v4 0/9] lib/group_cpus: rework grp_spread_init_one() and make it O(1) Yury Norov
2023-12-28 20:09 ` [PATCH 4/9] lib/group_cpus: optimize outer loop in grp_spread_init_one() Yury Norov
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=ZatlggW/8SH6od9O@fedora \
--to=ming.lei@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=nathan@kernel.org \
--cc=tglx@linutronix.de \
--cc=yury.norov@gmail.com \
--cc=ziy@nvidia.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