Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA

Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA

[Yury Norov]

Hi Rasmus!

> From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> Sent: Saturday, March 30, 2019 12:53:51 AM
> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko
> Cc: Yury Norov; linux-kernel@vger.kernel.org
> Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
> 
> The bitmap_remap, _bitremap, _onto and _fold functions are only used,
> via their node_ wrappers, in mm/mempolicy.c, which is only built for
> CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is
> global, but its only external caller is node_random() in lib/nodemask.c,
> which is also guarded by CONFIG_NUMA.

Nice catch. I think you should protect declaration of those functions
in include/linux/bitmap.h as well.

I'm concerned about pollution of such a generic portion of code with
subsystem-related #ifdefs. Would it make more sense to move numa-specific
stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h,
or whatever)?

Yury

> For !CONFIG_NUMA:
> 
> add/remove: 0/6 grow/shrink: 0/0 up/down: 0/-621 (-621)
> Function                                     old     new   delta
> bitmap_pos_to_ord                             20       -     -20
> bitmap_ord_to_pos                             70       -     -70
> bitmap_bitremap                               81       -     -81
> bitmap_fold                                  113       -    -113
> bitmap_onto                                  123       -    -123
> bitmap_remap                                 214       -    -214
> Total: Before=4776, After=4155, chg -13.00%
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  lib/bitmap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 66421f304f7d..3f3b8051f342 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -649,6 +649,7 @@ int bitmap_parselist_user(const char __user *ubuf,
>  EXPORT_SYMBOL(bitmap_parselist_user);
> 
> 
> +#ifdef CONFIG_NUMA
>  /**
>   * bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
>   *     @buf: pointer to a bitmap
> @@ -952,6 +953,7 @@ void bitmap_fold(unsigned long *dst, const unsigned long *orig,
>          for_each_set_bit(oldbit, orig, nbits)
>                  set_bit(oldbit % sz, dst);
>  }
> +#endif /* CONFIG_NUMA */
> 
>  /*
>   * Common code for bitmap_*_region() routines.
> --
> 2.20.1
> 

Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA

[Rasmus Villemoes]

On 30/03/2019 19.54, Yury Norov wrote:
> Hi Rasmus!
> 
>> From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> Sent: Saturday, March 30, 2019 12:53:51 AM
>> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko
>> Cc: Yury Norov; linux-kernel@vger.kernel.org
>> Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
>>
>> The bitmap_remap, _bitremap, _onto and _fold functions are only used,
>> via their node_ wrappers, in mm/mempolicy.c, which is only built for
>> CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is
>> global, but its only external caller is node_random() in lib/nodemask.c,
>> which is also guarded by CONFIG_NUMA.
> 
> Nice catch. I think you should protect declaration of those functions
> in include/linux/bitmap.h as well.

Yeah, well, it's not that simple, because one would also need to wrap
the static inline __nodes_onto etc. in ifdefs. Normally, there'd be an
#else branch defining simple static inline replacements that always fail
or return 0, but we can't do that here. So I'd prefer a simple linker
error should any user outside NUMA ever appear. Which I very highly doubt.

> I'm concerned about pollution of such a generic portion of code with
> subsystem-related #ifdefs. Would it make more sense to move numa-specific
> stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h,
> or whatever)?

Well, yes, that might be better, but a lot bigger patch. One could also
argue that bitmap.c is _already_ polluted with subsystem specific code
(though not in the form of preprocessor directives).

Dunno, I'll defer to Andrew's judgment.

Rasmus

Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA

[Yury Norov]

On Mon, Apr 01, 2019 at 10:10:33PM +0200, Rasmus Villemoes wrote:
> On 30/03/2019 19.54, Yury Norov wrote:
> > Hi Rasmus!
> > 
> >> From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> >> Sent: Saturday, March 30, 2019 12:53:51 AM
> >> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko
> >> Cc: Yury Norov; linux-kernel@vger.kernel.org
> >> Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
> >>
> >> The bitmap_remap, _bitremap, _onto and _fold functions are only used,
> >> via their node_ wrappers, in mm/mempolicy.c, which is only built for
> >> CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is
> >> global, but its only external caller is node_random() in lib/nodemask.c,
> >> which is also guarded by CONFIG_NUMA.
> > 
> > Nice catch. I think you should protect declaration of those functions
> > in include/linux/bitmap.h as well.
> 
> Yeah, well, it's not that simple, because one would also need to wrap
> the static inline __nodes_onto etc. in ifdefs. Normally, there'd be an
> #else branch defining simple static inline replacements that always fail
> or return 0, but we can't do that here.

There are enough examples of conditionally defined functions without
stubs, I don't see any problem with it. Anyways, if you don't like
doing that, moving the code and declarations to new files would help.

> So I'd prefer a simple linker
> error should any user outside NUMA ever appear. Which I very highly doubt.

Linker errors are usually less specific and much longer to obtain
at the linker-stage, which is not good.

> > I'm concerned about pollution of such a generic portion of code with
> > subsystem-related #ifdefs. Would it make more sense to move numa-specific
> > stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h,
> > or whatever)?
> 
> Well, yes, that might be better, but a lot bigger patch. One could also
> argue that bitmap.c is _already_ polluted with subsystem specific code
> (though not in the form of preprocessor directives).

I probably don't understand the argument. If we find bitmap.c polluted, we
should try clean it, right?