From: Yury Norov <yury.norov@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 2/2] bitmap: introduce for_each_set_bitrange
Date: Thu, 15 Jul 2021 08:50:21 -0700 [thread overview]
Message-ID: <YPBZPbCgJPjV2qPW@yury-ThinkPad> (raw)
In-Reply-To: <20210709095950.6a451ccb@oasis.local.home>
On Fri, Jul 09, 2021 at 09:59:50AM -0400, Steven Rostedt wrote:
> On Thu, 8 Jul 2021 20:45:19 -0700
> Yury Norov <yury.norov@gmail.com> wrote:
>
> > bitmap_list_string() is very ineffective when printing bitmaps with long
> > ranges of set bits because it calls find_next_bit for each bit. We can do
> > better by detecting ranges of set bits.
> >
> > This patch introduces a macro for_each_set_bitrange and uses it in
> > bitmap_list_string(). In my environment, before/after is 943008/31008 ns.
> >
> > Signed-off-by: Yury Norov <yury.norov@gmail.com>
> > ---
> > include/linux/find.h | 7 +++++++
> > lib/vsprintf.c | 40 ++++++++++++++++------------------------
> > 2 files changed, 23 insertions(+), 24 deletions(-)
> >
> > diff --git a/include/linux/find.h b/include/linux/find.h
> > index ae9ed52b52b8..1a5ed45dc81b 100644
> > --- a/include/linux/find.h
> > +++ b/include/linux/find.h
> > @@ -301,6 +301,13 @@ unsigned long find_next_bit_le(const void *addr, unsigned
> > (bit) < (size); \
> > (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
> >
> > +#define for_each_set_bitrange(b, e, addr, size) \
>
> The above needs a kerneldoc header.
OK.
>
> > + for ((b) = find_next_bit((addr), (size), 0), \
> > + (e) = find_next_zero_bit((addr), (size), (b) + 1); \
> > + (b) < (size); \
> > + (b) = find_next_bit((addr), (size), (e) + 1), \
> > + (e) = find_next_zero_bit((addr), (size), (b) + 1))
> > +
> > /**
> > * for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits
> > * @start: bit offset to start search and to store the current iteration offset
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 87acf66f0e4c..1ee54dace71e 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -1240,38 +1240,30 @@ char *bitmap_list_string(char *buf, char *end, unsigned long *bitmap,
> > struct printf_spec spec, const char *fmt)
> > {
> > int nr_bits = max_t(int, spec.field_width, 0);
> > - /* current bit is 'cur', most recently seen range is [rbot, rtop] */
> > - int cur, rbot, rtop;
> > - bool first = true;
> > + char *start = buf;
> > + int b, e;
> >
> > if (check_pointer(&buf, end, bitmap, spec))
> > return buf;
> >
> > - rbot = cur = find_first_bit(bitmap, nr_bits);
> > - while (cur < nr_bits) {
> > - rtop = cur;
> > - cur = find_next_bit(bitmap, nr_bits, cur + 1);
> > - if (cur < nr_bits && cur <= rtop + 1)
> > - continue;
> > + for_each_set_bitrange(b, e, bitmap, nr_bits) {
> > + buf = number(buf, end, b, default_dec_spec);
> > + if (e == b + 1)
> > + goto put_comma;
>
> Using a goto to skip a few lines instead of just having the reverse
> conditional is rather sloppy IMO.
>
> if (e != b + 1) {
> if (buf < end)
> *buf = '-';
> buf++;
> buf = number(buf, end, e - 1, default_dec_spec);
> }
>
> Is much clearer.
I don't think it's clearer, but as you wish.
> >
> > - if (!first) {
> > - if (buf < end)
> > - *buf = ',';
> > - buf++;
> > - }
> > - first = false;
> > + if (buf < end)
> > + *buf = '-';
> >
> > - buf = number(buf, end, rbot, default_dec_spec);
> > - if (rbot < rtop) {
> > - if (buf < end)
> > - *buf = '-';
> > - buf++;
> > + buf = number(++buf, end, e - 1, default_dec_spec);
> > +put_comma:
> > + if (buf < end)
> > + *buf = ',';
> > + buf++;
> > + }
> >
> > - buf = number(buf, end, rtop, default_dec_spec);
> > - }
> > + if (buf > start)
> > + buf--;
>
> If the above is to undo the last comma, please put back the first logic.
>
> -- Steve
You're asking me to move part of the logic inside the loop which generally
should be avoided. Is there any particular reason to do this?
>
> >
> > - rbot = cur;
> > - }
> > return buf;
> > }
> >
next prev parent reply other threads:[~2021-07-15 15:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-09 3:45 [PATCH 0/2] bitmap: introduce for_each_set_bitrange() Yury Norov
2021-07-09 3:45 ` [PATCH 1/2] lib: bitmap: add performance test for bitmap_print_to_pagebuf Yury Norov
2021-07-09 3:45 ` [PATCH 2/2] bitmap: introduce for_each_set_bitrange Yury Norov
2021-07-09 6:21 ` Yury Norov
2021-07-09 13:59 ` Steven Rostedt
2021-07-15 15:50 ` Yury Norov [this message]
2021-07-16 13:46 ` Petr Mladek
2021-07-16 17:05 ` 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=YPBZPbCgJPjV2qPW@yury-ThinkPad \
--to=yury.norov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tj@kernel.org \
/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.