| Message ID | 20230713125706.2884502-2-glider@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Implement MTE tag compression for swapped pages | expand |
+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.
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h index 03644237e1efb..8e36ce07bafd4 100644 --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -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 */
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(+)