All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Amritha Nambiar <amritha.nambiar@intel.com>,
	Willem de Bruijn <willemb@google.com>,
	Kees Cook <keescook@chromium.org>,
	Matthew Wilcox <willy@infradead.org>,
	"Tobin C . Harding" <tobin@kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Vineet Gupta <vineet.gupta1@synopsys.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	linux-kernel@vger.kernel.org
Cc: Yury Norov <ynorov@marvell.com>, Jens Axboe <axboe@kernel.dk>,
	Steffen Klassert <steffen.klassert@secunet.com>
Subject: Re: [PATCH 0/7] lib: rework bitmap_parse
Date: Tue, 7 May 2019 14:04:21 -0700	[thread overview]
Message-ID: <20190507210421.GA8935@yury-thinkpad> (raw)
In-Reply-To: <20190501010636.30595-1-ynorov@marvell.com>

On Tue, Apr 30, 2019 at 06:06:29PM -0700, Yury Norov wrote:
> On top of next-20190418.
> 
> Similarly to recently revisited bitmap_parselist() [1],
> bitmap_parse() is ineffective and overcomplicated.  This
> series reworks it, aligns its interface with bitmap_parselist()
> and makes usage simpler.
> 
> The series also adds a test for the function and fixes usage of it
> in cpumask_parse() according to new design - drops the calculating
> of length of an input string.
> 
> The following users would also consider to drop the length argument,
> if possible:
> drivers/block/drbd/drbd_main.c:2608
> kernel/padata.c:924
> net/core/net-sysfs.c:726
> net/core/net-sysfs.c:1309
> net/core/net-sysfs.c:1391
> 
> bitmap_parse() takes the array of numbers to be put into the map in
> the BE order which is reversed to the natural LE order for bitmaps.
> For example, to construct bitmap containing a bit on the position 42,
> we have to put a line '400,0'. Current implementation reads chunk
> one by one from the beginning ('400' before '0') and makes bitmap
> shift after each successful parse. It makes the complexity of the
> whole process as O(n^2). We can do it in reverse direction ('0'
> before '400') and avoid shifting, but it requires reverse parsing
> helpers.
> 
> Tested on arm64 and BE mips.

Any comments?

> v1: https://lkml.org/lkml/2019/4/27/597
> v2:
>  - strnchrnul() signature and description changed, ifdeffery and
>    exporting removed;
>  - test split for better demonstration of before/after changes;
>  - minor naming and formatting issues fixed.
> 
> [1] https://lkml.org/lkml/2019/4/16/66
> 
> Yury Norov (7):
>   lib/string: add strnchrnul()
>   bitops: more BITS_TO_* macros
>   lib: add test for bitmap_parse()
>   lib: make bitmap_parse_user a wrapper on bitmap_parse
>   lib: rework bitmap_parse()
>   lib: new testcases for bitmap_parse{_user}
>   cpumask: don't calculate length of the input string
> 
>  include/linux/bitmap.h       |   8 +-
>  include/linux/bitops.h       |   5 +-
>  include/linux/cpumask.h      |   4 +-
>  include/linux/string.h       |   1 +
>  lib/bitmap.c                 | 197 +++++++++++++++++------------------
>  lib/string.c                 |  17 +++
>  lib/test_bitmap.c            | 102 +++++++++++++++++-
>  tools/include/linux/bitops.h |   9 +-
>  8 files changed, 226 insertions(+), 117 deletions(-)
> 
> -- 
> 2.17.1

      parent reply	other threads:[~2019-05-07 21:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01  1:06 [PATCH 0/7] lib: rework bitmap_parse Yury Norov
2019-05-01  1:06 ` [PATCH 1/7] lib/string: add strnchrnul() Yury Norov
2019-05-08  8:47   ` Andy Shevchenko
2019-05-01  1:06 ` [PATCH 2/7] bitops: more BITS_TO_* macros Yury Norov
2019-05-08  8:47   ` Andy Shevchenko
2019-05-01  1:06 ` [PATCH 3/7] lib: add test for bitmap_parse() Yury Norov
2019-05-08  8:47   ` Andy Shevchenko
2019-05-01  1:06 ` [PATCH 4/7] lib: make bitmap_parse_user a wrapper on bitmap_parse Yury Norov
2019-05-08  8:47   ` Andy Shevchenko
2019-05-01  1:06 ` [PATCH 5/7] lib: rework bitmap_parse() Yury Norov
2019-05-08  8:46   ` Andy Shevchenko
2019-05-10  2:26     ` Yury Norov
2019-05-24  2:51       ` Andrew Morton
2019-05-01  1:06 ` [PATCH 6/7] lib: new testcases for bitmap_parse{_user} Yury Norov
2019-05-08  8:47   ` Andy Shevchenko
2019-05-01  1:06 ` [PATCH 7/7] cpumask: don't calculate length of the input string Yury Norov
2019-05-08  8:48   ` Andy Shevchenko
2019-05-07 21:04 ` Yury Norov [this message]

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=20190507210421.GA8935@yury-thinkpad \
    --to=yury.norov@gmail.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=amritha.nambiar@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=chris@chris-wilson.co.uk \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mszeredi@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=steffen.klassert@secunet.com \
    --cc=tobin@kernel.org \
    --cc=vineet.gupta1@synopsys.com \
    --cc=will.deacon@arm.com \
    --cc=willemb@google.com \
    --cc=willy@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.