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 <[email protected]>
---
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 <[email protected]>
> ---
>
> 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 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 <[email protected]>
>> ---
>>
>> 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 <[email protected]>
Thanks,
Tariq
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 <[email protected]>
> > ---
> >
> > 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 <[email protected]>
>> > ---
>> >
>> > 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 <[email protected]>
for this patch.