As an older version of the UP optimisation fixes was merged, not all
review feedback has been implemented. These patches implement the
feedback received on the merged version [1], and the respin [2], for
changes related to include/linux/cpumask.h and lib/cpumask.c.
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/[email protected]/
Sander Vanheule (3):
cpumask: align signatures of UP implementations
lib/cpumask: add inline cpumask_next_wrap() for UP
lib/cpumask: drop always-true preprocessor guard
include/linux/cpumask.h | 26 +++++++++++++++++++++++---
lib/Makefile | 3 ++-
lib/cpumask.c | 2 --
3 files changed, 25 insertions(+), 6 deletions(-)
--
2.37.1
Since lib/cpumask.o is only built for CONFIG_SMP=y, NR_CPUS will always
be greater than 1 at compile time. This makes checking for that
condition unnecesarry, so it can be dropped.
Signed-off-by: Sander Vanheule <[email protected]>
---
lib/cpumask.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 8baeb37e23d3..f0ae119be8c4 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -109,7 +109,6 @@ void __init free_bootmem_cpumask_var(cpumask_var_t mask)
}
#endif
-#if NR_CPUS > 1
/**
* cpumask_local_spread - select the i'th cpu with local numa cpu's first
* @i: index number
@@ -197,4 +196,3 @@ unsigned int cpumask_any_distribute(const struct cpumask *srcp)
return next;
}
EXPORT_SYMBOL(cpumask_any_distribute);
-#endif /* NR_CPUS */
--
2.37.1
In the uniprocessor case, cpumask_next_wrap() can be simplified, as the
number of valid argument combinations is limited:
- 'start' can only be 0
- 'n' can only be -1 or 0
The only valid CPU that can then be returned, if any, will be the first
one set in the provided 'mask'.
For NR_CPUS == 1, include/linux/cpumask.h now provides an inline
definition of cpumask_next_wrap(), which will conflict with the one
provided by lib/cpumask.c. Make building of lib/cpumask.o again depend
on CONFIG_SMP=y (i.e. NR_CPUS > 1) to avoid the re-definition.
Suggested-by: Yury Norov <[email protected]>
Signed-off-by: Sander Vanheule <[email protected]>
---
include/linux/cpumask.h | 19 +++++++++++++++++++
lib/Makefile | 3 ++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index d8c2a40f8beb..bd047864c7ac 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -262,7 +262,26 @@ unsigned int cpumask_next_and(int n, const struct cpumask *src1p,
(cpu) = cpumask_next_zero((cpu), (mask)), \
(cpu) < nr_cpu_ids;)
+#if NR_CPUS == 1
+static inline
+unsigned int cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap)
+{
+ cpumask_check(start);
+ if (n != -1)
+ cpumask_check(n);
+
+ /*
+ * Return the first available CPU when wrapping, or when starting before cpu0,
+ * since there is only one valid option.
+ */
+ if (wrap && n >= 0)
+ return nr_cpumask_bits;
+
+ return cpumask_first(mask);
+}
+#else
unsigned int __pure cpumask_next_wrap(int n, const struct cpumask *mask, int start, bool wrap);
+#endif
/**
* for_each_cpu_wrap - iterate over every cpu in a mask, starting at a specified location
diff --git a/lib/Makefile b/lib/Makefile
index c95212141928..5927d7fa0806 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -34,9 +34,10 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
earlycpio.o seq_buf.o siphash.o dec_and_lock.o \
nmi_backtrace.o win_minmax.o memcat_p.o \
- buildid.o cpumask.o
+ buildid.o
lib-$(CONFIG_PRINTK) += dump_stack.o
+lib-$(CONFIG_SMP) += cpumask.o
lib-y += kobject.o klist.o
obj-y += lockref.o
--
2.37.1
On Tue, Aug 09, 2022 at 07:36:32PM +0200, Sander Vanheule wrote:
> As an older version of the UP optimisation fixes was merged, not all
> review feedback has been implemented. These patches implement the
> feedback received on the merged version [1], and the respin [2], for
> changes related to include/linux/cpumask.h and lib/cpumask.c.
>
> [1] https://lore.kernel.org/lkml/[email protected]/
> [2] https://lore.kernel.org/lkml/[email protected]/
>
> Sander Vanheule (3):
> cpumask: align signatures of UP implementations
> lib/cpumask: add inline cpumask_next_wrap() for UP
> lib/cpumask: drop always-true preprocessor guard
Acked-by: Yury Norov <[email protected]>
Applying at bitmap-for-next, after some testing.
Thanks,
Yury
> include/linux/cpumask.h | 26 +++++++++++++++++++++++---
> lib/Makefile | 3 ++-
> lib/cpumask.c | 2 --
> 3 files changed, 25 insertions(+), 6 deletions(-)
>
> --
> 2.37.1
On Tue, 2022-08-09 at 21:55 -0700, Yury Norov wrote:
> On Tue, Aug 09, 2022 at 07:36:32PM +0200, Sander Vanheule wrote:
> > As an older version of the UP optimisation fixes was merged, not all
> > review feedback has been implemented. These patches implement the
> > feedback received on the merged version [1], and the respin [2], for
> > changes related to include/linux/cpumask.h and lib/cpumask.c.
> >
> > [1] https://lore.kernel.org/lkml/[email protected]/
> > [2] https://lore.kernel.org/lkml/[email protected]/
> >
> > Sander Vanheule (3):
> > cpumask: align signatures of UP implementations
> > lib/cpumask: add inline cpumask_next_wrap() for UP
> > lib/cpumask: drop always-true preprocessor guard
>
> Acked-by: Yury Norov <[email protected]>
>
> Applying at bitmap-for-next, after some testing.
Thanks! Any chance to get this in for 6.0? I would rather avoid building cpumask.o only on 6.0, but
otherwise I don't think anything is functionally wrong with what is currently merged.
Best,
Sander
On Wed, 2022-08-10 at 01:39 -0700, Yury Norov wrote:
> On Wed, Aug 10, 2022 at 10:18:09AM +0200, Sander Vanheule wrote:
> > On Tue, 2022-08-09 at 21:55 -0700, Yury Norov wrote:
> > > On Tue, Aug 09, 2022 at 07:36:32PM +0200, Sander Vanheule wrote:
> > > > As an older version of the UP optimisation fixes was merged, not all
> > > > review feedback has been implemented. These patches implement the
> > > > feedback received on the merged version [1], and the respin [2], for
> > > > changes related to include/linux/cpumask.h and lib/cpumask.c.
> > > >
> > > > [1] https://lore.kernel.org/lkml/[email protected]/
> > > > [2] https://lore.kernel.org/lkml/[email protected]/
> > > >
> > > > Sander Vanheule (3):
> > > > cpumask: align signatures of UP implementations
> > > > lib/cpumask: add inline cpumask_next_wrap() for UP
> > > > lib/cpumask: drop always-true preprocessor guard
> > >
> > > Acked-by: Yury Norov <[email protected]>
> > >
> > > Applying at bitmap-for-next, after some testing.
> >
> > Thanks! Any chance to get this in for 6.0? I would rather avoid building cpumask.o only on 6.0,
> > but
> > otherwise I don't think anything is functionally wrong with what is currently merged.
>
> Functionally not, but something is still wrong, right? :)
>
> I think -rc2 would be our best option for this, because this series is
> a fix to v4, and because it will let this spend some time in -next.
>
> Are you OK with this?
Sounds perfect!
Thanks,
Sander
On Wed, Aug 10, 2022 at 10:18:09AM +0200, Sander Vanheule wrote:
> On Tue, 2022-08-09 at 21:55 -0700, Yury Norov wrote:
> > On Tue, Aug 09, 2022 at 07:36:32PM +0200, Sander Vanheule wrote:
> > > As an older version of the UP optimisation fixes was merged, not all
> > > review feedback has been implemented.? These patches implement the
> > > feedback received on the merged version [1], and the respin [2], for
> > > changes related to include/linux/cpumask.h and lib/cpumask.c.
> > >
> > > [1] https://lore.kernel.org/lkml/[email protected]/
> > > [2] https://lore.kernel.org/lkml/[email protected]/
> > >
> > > Sander Vanheule (3):
> > > ? cpumask: align signatures of UP implementations
> > > ? lib/cpumask: add inline cpumask_next_wrap() for UP
> > > ? lib/cpumask: drop always-true preprocessor guard
> >
> > Acked-by: Yury Norov <[email protected]>
> >
> > Applying at bitmap-for-next, after some testing.
>
> Thanks! Any chance to get this in for 6.0? I would rather avoid building cpumask.o only on 6.0, but
> otherwise I don't think anything is functionally wrong with what is currently merged.
Functionally not, but something is still wrong, right? :)
I think -rc2 would be our best option for this, because this series is
a fix to v4, and because it will let this spend some time in -next.
Are you OK with this?
Thanks,
Yury