[v2,1/5] lib/bitmap: add bitmap_{set,get}_value_unaligned()
Commit Message
The two new functions allow setting/getting values of length up to
BITS_PER_LONG bits at arbitrary position in the bitmap.
Suggested-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
---
include/linux/bitmap.h | 63 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
Comments
+Cc: William
On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> The two new functions allow setting/getting values of length up to
> BITS_PER_LONG bits at arbitrary position in the bitmap.
A couple of years (?) ago it was a series to achieve something like this with
better (?) code. Why not resurrect that one?
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
On Thu, Jul 13, 2023 at 7:29 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> +Cc: William
>
> On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> > The two new functions allow setting/getting values of length up to
> > BITS_PER_LONG bits at arbitrary position in the bitmap.
>
> A couple of years (?) ago it was a series to achieve something like this with
> better (?) code. Why not resurrect that one?
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
It looks more compact thanks to GENMASK, I can cook something based on
the proposed bitmap_{set,get}_value (and change the names if you
prefer the shorter ones).
But I'd better avoid pulling in the rest of that series without a strong need.
> --
> With Best Regards,
> Andy Shevchenko
>
>
On Thu, Jul 13, 2023 at 08:05:34PM +0200, Alexander Potapenko wrote:
> On Thu, Jul 13, 2023 at 7:29 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > +Cc: William
> >
> > On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> > > The two new functions allow setting/getting values of length up to
> > > BITS_PER_LONG bits at arbitrary position in the bitmap.
> >
> > A couple of years (?) ago it was a series to achieve something like this with
> > better (?) code. Why not resurrect that one?
> >
> > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
>
> It looks more compact thanks to GENMASK, I can cook something based on
> the proposed bitmap_{set,get}_value (and change the names if you
> prefer the shorter ones).
> But I'd better avoid pulling in the rest of that series without a strong need.
William, what do you think on this?
I'm personally prefer William's version as not only it was published first
it was carefully designed and got a lot of review already. We just hadn't had
the user for it that time.
On Fri, Jul 14, 2023 at 11:04:16AM +0300, Andy Shevchenko wrote:
> On Thu, Jul 13, 2023 at 08:05:34PM +0200, Alexander Potapenko wrote:
> > On Thu, Jul 13, 2023 at 7:29 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > +Cc: William
> > >
> > > On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> > > > The two new functions allow setting/getting values of length up to
> > > > BITS_PER_LONG bits at arbitrary position in the bitmap.
> > >
> > > A couple of years (?) ago it was a series to achieve something like this with
> > > better (?) code. Why not resurrect that one?
> > >
> > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
> >
> > It looks more compact thanks to GENMASK, I can cook something based on
> > the proposed bitmap_{set,get}_value (and change the names if you
> > prefer the shorter ones).
> > But I'd better avoid pulling in the rest of that series without a strong need.
>
> William, what do you think on this?
>
> I'm personally prefer William's version as not only it was published first
> it was carefully designed and got a lot of review already. We just hadn't had
> the user for it that time.
>
> --
> With Best Regards,
> Andy Shevchenko
Yes, that version went through several revisions so it's been well
tested and known to work -- as you pointed out it just lacked the users
to warrant merging it into the tree. If it statisfies the use-case
required here now, then I think we should it pick it up rather than
reinvent the solution again.
Also, we probably don't need the "clump" code in there, so perhaps
splitting it out to just the bitmap_{set,get}_value relevant code is
fine.
William Breathitt Gray
On Fri, Jul 14, 2023 at 07:19:15AM -0400, William Breathitt Gray wrote:
> On Fri, Jul 14, 2023 at 11:04:16AM +0300, Andy Shevchenko wrote:
> > On Thu, Jul 13, 2023 at 08:05:34PM +0200, Alexander Potapenko wrote:
> > > On Thu, Jul 13, 2023 at 7:29 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> > > > > The two new functions allow setting/getting values of length up to
> > > > > BITS_PER_LONG bits at arbitrary position in the bitmap.
> > > >
> > > > A couple of years (?) ago it was a series to achieve something like this with
> > > > better (?) code. Why not resurrect that one?
> > > >
> > > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
> > >
> > > It looks more compact thanks to GENMASK, I can cook something based on
> > > the proposed bitmap_{set,get}_value (and change the names if you
> > > prefer the shorter ones).
> > > But I'd better avoid pulling in the rest of that series without a strong need.
> >
> > William, what do you think on this?
> >
> > I'm personally prefer William's version as not only it was published first
> > it was carefully designed and got a lot of review already. We just hadn't had
> > the user for it that time.
>
> Yes, that version went through several revisions so it's been well
> tested and known to work -- as you pointed out it just lacked the users
> to warrant merging it into the tree. If it statisfies the use-case
> required here now, then I think we should it pick it up rather than
> reinvent the solution again.
>
> Also, we probably don't need the "clump" code in there, so perhaps
> splitting it out to just the bitmap_{set,get}_value relevant code is
> fine.
Agree, thank you for your comments!
On Fri, Jul 14, 2023 at 1:28 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jul 14, 2023 at 07:19:15AM -0400, William Breathitt Gray wrote:
> > On Fri, Jul 14, 2023 at 11:04:16AM +0300, Andy Shevchenko wrote:
> > > On Thu, Jul 13, 2023 at 08:05:34PM +0200, Alexander Potapenko wrote:
> > > > On Thu, Jul 13, 2023 at 7:29 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > On Thu, Jul 13, 2023 at 02:57:01PM +0200, Alexander Potapenko wrote:
> > > > > > The two new functions allow setting/getting values of length up to
> > > > > > BITS_PER_LONG bits at arbitrary position in the bitmap.
> > > > >
> > > > > A couple of years (?) ago it was a series to achieve something like this with
> > > > > better (?) code. Why not resurrect that one?
> > > > >
> > > > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2195426.html
> > > >
> > > > It looks more compact thanks to GENMASK, I can cook something based on
> > > > the proposed bitmap_{set,get}_value (and change the names if you
> > > > prefer the shorter ones).
> > > > But I'd better avoid pulling in the rest of that series without a strong need.
> > >
> > > William, what do you think on this?
> > >
> > > I'm personally prefer William's version as not only it was published first
> > > it was carefully designed and got a lot of review already. We just hadn't had
> > > the user for it that time.
> >
> > Yes, that version went through several revisions so it's been well
> > tested and known to work -- as you pointed out it just lacked the users
> > to warrant merging it into the tree. If it statisfies the use-case
> > required here now, then I think we should it pick it up rather than
> > reinvent the solution again.
> >
> > Also, we probably don't need the "clump" code in there, so perhaps
> > splitting it out to just the bitmap_{set,get}_value relevant code is
> > fine.
>
> Agree, thank you for your comments!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
So would it be fine if I split off bitmap_set_value() and
bitmap_get_value() from that series and send it (with the appropriate
attribution) instead of my patch 1/5?
We'll probably still need to retain patch 2/5 (with the function names changed).
On Fri, Jul 14, 2023 at 02:07:45PM +0200, Alexander Potapenko wrote:
> On Fri, Jul 14, 2023 at 1:28 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Jul 14, 2023 at 07:19:15AM -0400, William Breathitt Gray wrote:
> > > On Fri, Jul 14, 2023 at 11:04:16AM +0300, Andy Shevchenko wrote:
> > > > On Thu, Jul 13, 2023 at 08:05:34PM +0200, Alexander Potapenko wrote:
...
> > > > William, what do you think on this?
> > > >
> > > > I'm personally prefer William's version as not only it was published first
> > > > it was carefully designed and got a lot of review already. We just hadn't had
> > > > the user for it that time.
> > >
> > > Yes, that version went through several revisions so it's been well
> > > tested and known to work -- as you pointed out it just lacked the users
> > > to warrant merging it into the tree. If it statisfies the use-case
> > > required here now, then I think we should it pick it up rather than
> > > reinvent the solution again.
> > >
> > > Also, we probably don't need the "clump" code in there, so perhaps
> > > splitting it out to just the bitmap_{set,get}_value relevant code is
> > > fine.
> >
> > Agree, thank you for your comments!
> So would it be fine if I split off bitmap_set_value() and
> bitmap_get_value() from that series and send it (with the appropriate
> attribution) instead of my patch 1/5?
> We'll probably still need to retain patch 2/5 (with the function names
> changed).
Sounds good to me.
@@ -77,6 +77,8 @@ struct device;
* bitmap_to_arr64(buf, src, nbits) Copy nbits from buf to u64[] dst
* bitmap_get_value8(map, start) Get 8bit value from map at start
* bitmap_set_value8(map, value, start) Set 8bit value to map at start
+ * bitmap_get_value_unaligned(map, start, nbits) Get value up to BITS_PER_LONG
+ * bitmap_set_value_unaligned(map, value, start, nbits) Set value up to BITS_PER_LONG
*
* Note, bitmap_zero() and bitmap_fill() operate over the region of
* unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -583,6 +585,35 @@ static inline unsigned long bitmap_get_value8(const unsigned long *map,
return (map[index] >> offset) & 0xFF;
}
+/**
+ * bitmap_get_value_unaligned - get an @nbits-bit value within a memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the value; may not be a multiple of 8
+ * @nbits: number of bits to get
+ *
+ * Returns the @nbits-sized value located at the @start bit offset within the
+ * @map memory region.
+ */
+static inline unsigned long bitmap_get_value_unaligned(const unsigned long *map,
+ unsigned long start,
+ unsigned long nbits)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+ const unsigned long carry = (offset + nbits) % BITS_PER_LONG;
+ unsigned long hi, lo, result;
+
+ if (offset + nbits <= BITS_PER_LONG) {
+ result = map[index] >> (BITS_PER_LONG - offset - nbits);
+ return result & BITMAP_LAST_WORD_MASK(nbits);
+ }
+
+ hi = map[index] & BITMAP_LAST_WORD_MASK(BITS_PER_LONG - offset);
+ lo = map[index + 1] & BITMAP_FIRST_WORD_MASK(BITS_PER_LONG - carry);
+ lo >>= (BITS_PER_LONG - carry);
+ return (hi << carry) | lo;
+}
+
/**
* bitmap_set_value8 - set an 8-bit value within a memory region
* @map: address to the bitmap memory region
@@ -599,6 +630,38 @@ static inline void bitmap_set_value8(unsigned long *map, unsigned long value,
map[index] |= value << offset;
}
+/**
+ * bitmap_set_value_unaligned - set an @nbits-bit value within a memory region
+ * @map: address to the bitmap memory region
+ * @value: the value up to BITS_PER_LONG bits (will be clamped to @nbits)
+ * @start: bit offset of the value; may not be a multiple of 8
+ * @nbits: number of bits to set
+ */
+static inline void bitmap_set_value_unaligned(unsigned long *map,
+ unsigned long value,
+ unsigned long start,
+ unsigned long nbits)
+{
+ const size_t index = BIT_WORD(start);
+ const unsigned long offset = start % BITS_PER_LONG;
+ unsigned long mask = BITMAP_LAST_WORD_MASK(nbits);
+ const unsigned long carry = (offset + nbits) % BITS_PER_LONG;
+
+ value &= mask;
+ if (offset + nbits <= BITS_PER_LONG) {
+ value <<= (BITS_PER_LONG - offset - nbits);
+ mask <<= (BITS_PER_LONG - offset - nbits);
+ map[index] &= ~mask;
+ map[index] |= value;
+ return;
+ }
+ map[index] &= ~BITMAP_LAST_WORD_MASK(BITS_PER_LONG - offset);
+ map[index] |= (value >> (carry));
+ value &= BITMAP_LAST_WORD_MASK(carry);
+ map[index + 1] &= ~BITMAP_FIRST_WORD_MASK(BITS_PER_LONG - carry);
+ map[index + 1] |= value << (BITS_PER_LONG - carry);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* __LINUX_BITMAP_H */