Now that we have an iterator-based alternative for a very common case
of using cpumask_local_spread for all cpus in a row, it's worth to
mention it in comment to cpumask_local_spread().

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---

Hi Tariq, Valentin,

I rebased your iterators patches on top of cpumask_local_spread() rework.
(Rebase is not plain simple.) The result is on bitmap-for-next branch,
and in -next too. 

This patch adds a note on alternative approach in cpumask_local_spread()
comment, as we discussed before.

I'm going to send pull request with cpumask_local_spread() rework by the
end of this week. If you want, I can include your patches in the request.
Otherwise please consider appending this patch to your series.

Thanks,
Yury

 lib/cpumask.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/lib/cpumask.c b/lib/cpumask.c
index 10aa15715c0d..98291b07c756 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -114,11 +114,29 @@ void __init free_bootmem_cpumask_var(cpumask_var_t mask)
  * @i: index number
  * @node: local numa_node
  *
- * This function selects an online CPU according to a numa aware policy;
- * local cpus are returned first, followed by non-local ones, then it
- * wraps around.
+ * Returns an online CPU according to a numa aware policy; local cpus are
+ * returned first, followed by non-local ones, then it wraps around.
  *
- * It's not very efficient, but useful for setup.
+ * For those who want to enumerate all CPUs based on their NUMA distances,
+ * i.e. call this function in a loop, like:
+ *
+ * for (i = 0; i < num_online_cpus(); i++) {
+ *	cpu = cpumask_local_spread();
+ *	do_something(cpu);
+ * }
+ *
+ * There's a better alternative based on for_each()-like iterators:
+ *
+ *	for_each_numa_hop_mask(mask, node) {
+ *		for_each_cpu_andnot(cpu, mask, prev)
+ *			do_something(cpu);
+ *		prev = mask;
+ *	}
+ *
+ * It's simpler and more verbose than above. Complexity of iterator-based
+ * enumeration is O(sched_domains_numa_levels * nr_cpu_ids), while
+ * cpumask_local_spread() when called for each cpu is
+ * O(sched_domains_numa_levels * nr_cpu_ids * log(nr_cpu_ids)).
  */
 unsigned int cpumask_local_spread(unsigned int i, int node)
 {
-- 
2.34.1

On 12/12/22 20:32, Yury Norov wrote:
> Now that we have an iterator-based alternative for a very common case
> of using cpumask_local_spread for all cpus in a row, it's worth to
> mention it in comment to cpumask_local_spread().
>
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
> ---
>
> Hi Tariq, Valentin,
>
> I rebased your iterators patches on top of cpumask_local_spread() rework.
> (Rebase is not plain simple.) The result is on bitmap-for-next branch,
> and in -next too.
>

I had a look, LGTM.

> This patch adds a note on alternative approach in cpumask_local_spread()
> comment, as we discussed before.
>
> I'm going to send pull request with cpumask_local_spread() rework by the
> end of this week. If you want, I can include your patches in the request.
> Otherwise please consider appending this patch to your series.
>

It would probably make sense to send it all together, especially since you
went through the trouble of rebasing the patches :)

Thanks!

On Wed, Dec 14, 2022 at 09:47:47AM +0000, Valentin Schneider wrote:
> On 12/12/22 20:32, Yury Norov wrote:
> > Now that we have an iterator-based alternative for a very common case
> > of using cpumask_local_spread for all cpus in a row, it's worth to
> > mention it in comment to cpumask_local_spread().
> >
> > Signed-off-by: Yury Norov <yury.norov@gmail.com>
> > ---
> >
> > Hi Tariq, Valentin,
> >
> > I rebased your iterators patches on top of cpumask_local_spread() rework.
> > (Rebase is not plain simple.) The result is on bitmap-for-next branch,
> > and in -next too.
> >
> 
> I had a look, LGTM.

Does it mean reviewed-by? If so - for the whole cpumask_local_spread()
series, or for the last patch?

On 14/12/22 08:48, Yury Norov wrote:
> On Wed, Dec 14, 2022 at 09:47:47AM +0000, Valentin Schneider wrote:
>> On 12/12/22 20:32, Yury Norov wrote:
>> > Now that we have an iterator-based alternative for a very common case
>> > of using cpumask_local_spread for all cpus in a row, it's worth to
>> > mention it in comment to cpumask_local_spread().
>> >
>> > Signed-off-by: Yury Norov <yury.norov@gmail.com>
>> > ---
>> >
>> > Hi Tariq, Valentin,
>> >
>> > I rebased your iterators patches on top of cpumask_local_spread() rework.
>> > (Rebase is not plain simple.) The result is on bitmap-for-next branch,
>> > and in -next too.
>> >
>>
>> I had a look, LGTM.
>
> Does it mean reviewed-by? If so - for the whole cpumask_local_spread()
> series, or for the last patch?

Ah sorry, I meant I had a look at your branch for the result of the rebase
which looks sane to me.

Feel free to add
  Reviewed-by: Valentin Schneider <vschneid@redhat.com>
for this patch.

On 12/14/2022 11:47 AM, Valentin Schneider wrote:
> On 12/12/22 20:32, Yury Norov wrote:
>> Now that we have an iterator-based alternative for a very common case
>> of using cpumask_local_spread for all cpus in a row, it's worth to
>> mention it in comment to cpumask_local_spread().
>>
>> Signed-off-by: Yury Norov <yury.norov@gmail.com>
>> ---
>>
>> Hi Tariq, Valentin,
>>
>> I rebased your iterators patches on top of cpumask_local_spread() rework.
>> (Rebase is not plain simple.) The result is on bitmap-for-next branch,
>> and in -next too.
>>
> 
> I had a look, LGTM.
> 
>> This patch adds a note on alternative approach in cpumask_local_spread()
>> comment, as we discussed before.
>>
>> I'm going to send pull request with cpumask_local_spread() rework by the
>> end of this week. If you want, I can include your patches in the request.
>> Otherwise please consider appending this patch to your series.
>>
> 
> It would probably make sense to send it all together, especially since you
> went through the trouble of rebasing the patches :)
> 
> Thanks!
> 

Same here.

Reviewed-by: Tariq Toukan <tariqt@nvidia.com>

Thanks,
Tariq