From: Yury <yury.norov@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
George Spelvin <linux@horizon.com>
Cc: akpm@linux-foundation.org, chris@chris-wilson.co.uk,
davem@davemloft.net, dborkman@redhat.com,
hannes@stressinduktion.org, klimov.linux@gmail.com,
laijs@cn.fujitsu.com, msalter@redhat.com,
takahiro.akashi@linaro.org, tgraf@suug.ch,
valentinrothberg@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] lib: find_*_bit reimplementation
Date: Thu, 12 Feb 2015 02:05:11 +0300 [thread overview]
Message-ID: <54DBE027.3010209@gmail.com> (raw)
In-Reply-To: <87wq3rs3lp.fsf@rasmusvillemoes.dk>
On 09.02.2015 14:53, Rasmus Villemoes wrote:
> [Yury, please do remember to Cc everyone who has previously
> participated]
>
> On Mon, Feb 09 2015, "George Spelvin" <linux@horizon.com> wrote:
>
>> Two more comments on the code. Two minor, but one that
>> seems like a bug, so for now, it's
>>
>> Nacked-by: George Spelvin <linux@horizon.com>
>>
>> Specifically, it seems like find_last_bit used to ignore trailing
>> garbage in the bitmap, but now will stop searching if the last word
>> contains some set bits not within size.
> True, though see below.
>
>> The minor one is that I don't think the first-word masking needs to
>> be conditional. The general code works fine if the start is aligned
>> (HIGH_BITS_MASK just generates an all-ones mask), is quite quick, and
>> saves a test & conditional branch.
>>
> I also noted that during the first review, but when I tried to compile
> it gcc actually generated slightly worse code, so I decided not to
> comment on it. I don't have a strong preference either way, though.
>
>> Previously, the last word was masked, so bits beyond "size" were ignored.
>> With the revised code, something like find_last_bit(array, 96) will return 96
>> if array[1] >> 32 is non-zero, even if array[1] & 0xffffffff is zero.
>>
>> Looking through the callers, I haven't found a case where this matters yet
>> so perhaps it's a safe optimization, but this really needs to be more
>> clearly documented if intentional.
>>
>> If no change was desired, I'd think a good way to do this would be:
>>
>> unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
>> {
>> size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);
>> unsigned long tmp = addr[--idx];
>>
>> tmp &= (2UL << (size % BITS_PER_LONG)) - 1; /* Mask last word */
>>
>> while (!tmp) {
>> if (!idx)
>> return size;
>> tmp = addr[--idx];
>> }
>> return idx * BITS_PER_LONG + __fls(tmp);
>> }
> How should that work? If size is for example 1, the mask evaluates to 3UL,
> while what is needed is 1UL. If size is aligned, the mask becomes 1UL,
> which is also not right.
>
> Also, I think it is best to handle size==0 appropriately, meaning that
> one cannot dereference addr in any way (and certainly not addr[-1]).
>
> So how about
>
> unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
> {
> size_t idx = DIV_ROUND_UP(size, BITS_PER_LONG);
> unsigned long mask = LAST_WORD_MASK(size);
>
> while (idx--) {
> unsigned long val = addr[idx] & mask;
> if (val)
> return idx * BITS_PER_LONG + __fls(val);
> mask = ~0ul;
> }
> return size;
> }
>
> Rasmus
Rasmus, your version has ANDing by mask, and resetting the mask at each iteration
of main loop. I think we can avoid it. What do you think on next?
unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
{
size_t idx;
unsigned long tmp;
if (!size)
return 0;
idx = DIV_ROUND_UP(size, BITS_PER_LONG) - 1;
tmp = addr[idx] & LAST_WORD_MASK(size);
while (!tmp) {
if (!idx--)
return size;
tmp = addr[idx];
}
return idx * BITS_PER_LONG + __fls(tmp);
}
Yury
next prev parent reply other threads:[~2015-02-11 23:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-08 14:10 [PATCH v3 0/3] lib: find_*_bit reimplementation Yury Norov
2015-02-08 14:10 ` [PATCH v3 1/3] " Yury Norov
2015-02-08 18:48 ` George Spelvin
2015-02-09 8:32 ` George Spelvin
2015-02-09 11:53 ` Rasmus Villemoes
2015-02-09 16:45 ` George Spelvin
2015-02-11 22:14 ` Rasmus Villemoes
2015-02-11 23:05 ` Yury [this message]
2015-02-12 8:15 ` George Spelvin
2015-02-12 9:58 ` Rasmus Villemoes
2015-02-12 23:46 ` George Spelvin
2015-02-13 10:13 ` Rasmus Villemoes
2015-02-08 14:10 ` [PATCH v3 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-08 14:10 ` [PATCH v3 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-17 2:35 ` [PATCH v4 0/3] lib: find_*_bit reimplementation Yury Norov
2015-02-17 2:35 ` [PATCH v4 1/3] " Yury Norov
2015-02-18 17:57 ` Rasmus Villemoes
2015-02-17 2:35 ` [PATCH v4 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-17 2:35 ` [PATCH v4 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-22 17:24 ` [PATCH v5 0/3] lib: find_*_bit reimplementation Yury Norov
2015-02-22 17:24 ` [PATCH v5 1/3] " Yury Norov
2015-02-23 21:50 ` Rasmus Villemoes
2015-02-24 0:29 ` George Spelvin
2015-02-22 17:24 ` [PATCH v5 2/3] lib: move find_last_bit to lib/find_next_bit.c Yury Norov
2015-02-22 17:24 ` [PATCH v5 3/3] lib: rename lib/find_next_bit.c to lib/find_bit.c Yury Norov
2015-02-24 0:40 ` [PATCH v5 0/3] lib: find_*_bit reimplementation Andrew Morton
2015-03-08 18:17 ` Yury Norov
[not found] <CAAH8bW-mk0kk-GKDNny6hsjrbcjwdcAacsF_DEaXmNG==hXhRw@mail.gmail.com>
2015-02-13 21:09 ` [PATCH v3 1/3] " George Spelvin
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=54DBE027.3010209@gmail.com \
--to=yury.norov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=hannes@stressinduktion.org \
--cc=klimov.linux@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=linux@rasmusvillemoes.dk \
--cc=msalter@redhat.com \
--cc=takahiro.akashi@linaro.org \
--cc=tgraf@suug.ch \
--cc=valentinrothberg@gmail.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.