linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Yury Norov <yury.norov@gmail.com>,
	Yury Norov <ynorov@marvell.com>
Subject: Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
Date: Sat, 30 Mar 2019 21:54:36 +0300	[thread overview]
Message-ID: <20190330185436.GA19813@yury-thinkpad> (raw)

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
> 

             reply	other threads:[~2019-03-30 18:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30 18:54 Yury Norov [this message]
2019-04-01 20:10 ` PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA Rasmus Villemoes
2019-04-02 11:45   ` 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=20190330185436.GA19813@yury-thinkpad \
    --to=yury.norov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=ynorov@marvell.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;
as well as URLs for NNTP newsgroup(s).