search for: ulong_max

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new

On 12/22/2017 05:03 AM, Matthew Wilcox wrote: > OK, here's a rewrite of xbitmap. > > Compared to the version you sent: > - xb_find_set() is the rewrite I sent out yesterday. > - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find > clear bits. This led to me finding a bug in radix_tree_for_each_tagged(). > - xb_zero() is also a new

On Wed, Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: > On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: > > unsigned long bit; > > xb_preload(GFP_KERNEL); > > xb_set_bit(xb, 700); > > xb_preload_end(); > > bit = xb_find_set(xb, ULONG_MAX, 0); > > assert(bit == 700); > > This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. > > A better test would be > ... > xb_set_bit(xb, 700); > assert(xb_find_set(xb, ULONG_MAX, 8...

...the future. > > You can't remove the !node path. You'll see !node when the highest set bit > is less than 1024. So do something like this: > > unsigned long bit; > xb_preload(GFP_KERNEL); > xb_set_bit(xb, 700); > xb_preload_end(); > bit = xb_find_set(xb, ULONG_MAX, 0); > assert(bit == 700); This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. A better test would be ... xb_set_bit(xb, 700); assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); ... The first try wi...

...the future. > > You can't remove the !node path. You'll see !node when the highest set bit > is less than 1024. So do something like this: > > unsigned long bit; > xb_preload(GFP_KERNEL); > xb_set_bit(xb, 700); > xb_preload_end(); > bit = xb_find_set(xb, ULONG_MAX, 0); > assert(bit == 700); This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. A better test would be ... xb_set_bit(xb, 700); assert(xb_find_set(xb, ULONG_MAX, 800) == ULONG_MAX); ... The first try wi...

...(nbits == IDA_BITMAP_BITS || + bitmap_empty(bitmap->bitmap, IDA_BITMAP_BITS)) { + kfree(bitmap); + __radix_tree_delete(root, node, slot); + } + } + + /* + * Already reached the last usable ida bitmap, so just return, + * otherwise overflow will happen. + */ + if (index == ULONG_MAX / IDA_BITMAP_BITS) + break; + } +} +EXPORT_SYMBOL(xb_clear_bit_range); + +/** * xb_test_bit - test a bit in the xbitmap * @xb: the xbitmap tree used to record the bit * @bit: index of the bit to test @@ -143,6 +229,87 @@ bool xb_test_bit(const struct xb *xb, unsigned long bit) } EXPORT_SY...

...def __KERNEL__ + +static DEFINE_XB(xb1); + +static void xbitmap_check_bit(unsigned long bit) +{ + unsigned long nbit = 0; + + xb_preload(GFP_KERNEL); + assert(!xb_test_bit(&xb1, bit)); + assert(xb_set_bit(&xb1, bit) == 0); + assert(xb_test_bit(&xb1, bit)); + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true); + assert(nbit == bit); + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true); + assert(nbit == bit); + nbit++; + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == false); + assert(nbit == bit + 1); + xb_clear_bit(&xb1, bit); + assert(xb_empty(&xb1)); + xb_c...

...t, xb_clear_bit, xb_clear_bit_range, xb_test_bit, + * xb_find_set, or xb_find_clear to operate on the same ida bitmap. + * - The current implementation of xb_clear_bit_range, xb_find_set and + * xb_find_clear may cause long latency when the bit range to operate + * on is super large (e.g. [0, ULONG_MAX]). + */ + /** * xb_set_bit - set a bit in the xbitmap * @xb: the xbitmap tree used to record the bit @@ -72,6 +82,49 @@ void xb_clear_bit(struct xb *xb, unsigned long bit) EXPORT_SYMBOL(xb_clear_bit); /** + * xb_clear_bit_range - clear a range of bits in the xbitmap + * @start: the start...

...t, xb_clear_bit, xb_clear_bit_range, xb_test_bit, + * xb_find_set, or xb_find_clear to operate on the same ida bitmap. + * - The current implementation of xb_clear_bit_range, xb_find_set and + * xb_find_clear may cause long latency when the bit range to operate + * on is super large (e.g. [0, ULONG_MAX]). + */ + /** * xb_set_bit - set a bit in the xbitmap * @xb: the xbitmap tree used to record the bit @@ -72,6 +82,49 @@ void xb_clear_bit(struct xb *xb, unsigned long bit) EXPORT_SYMBOL(xb_clear_bit); /** + * xb_clear_bit_range - clear a range of bits in the xbitmap + * @start: the start...

...def __KERNEL__ + +static DEFINE_XB(xb1); + +static void xbitmap_check_bit(unsigned long bit) +{ + unsigned long nbit = 0; + + xb_preload(GFP_KERNEL); + assert(!xb_test_bit(&xb1, bit)); + assert(xb_set_bit(&xb1, bit) == 0); + assert(xb_test_bit(&xb1, bit)); + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true); + assert(nbit == bit); + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == true); + assert(nbit == bit); + nbit++; + assert(xb_find_set(&xb1, ULONG_MAX, &nbit) == false); + assert(nbit == bit + 1); + xb_clear_bit(&xb1, bit); + assert(xb_empty(&xb1)); + xb_c...

Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which we are now using in -current. OpenBSD defines it as ULONG_MAX. Pawing through the Solaris /usr/include it stated it could be 'u_int' or 'u_long'. Depends on if your are compiling legacy stuff. I'm sure other OSes may encounter this issue (not tried Linux, but Redhat 7.x does not define it), but what is the collective suggestion in rega...

...e usage of the xb_ related APIs v19->v20: 1) patch 1: xbitmap - add __rcu to "void **slot"; - remove the exceptional path. 2) patch 3: xbitmap - DeveloperNotes: add an item to comment that the current bit range related APIs operating on extremely large ranges (e.g. [0, ULONG_MAX)) will take too long time. This can be optimized in the future. - remove the exceptional path; - remove xb_preload_and_set(); - reimplement xb_clear_bit_range to make its usage close to bitmap_clear; - rename xb_find_next_set_bit to xb_find_set, and re-implement it in a style close to...

...gt;> + unsigned long tmp = (unsigned long)bitmap; >>>> + >>>> + nbits = min(end - start + 1, BITS_PER_LONG - ebit); >>>> + >>>> + if (ebit >= BITS_PER_LONG) >>> What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ? >> Thanks. I also improved the test case for this. I plan to change the >> implementation a little bit to avoid such overflow (has passed the test >> case that I have, just post out for another set of eyes): >> >> { >> ... >>...

...Dec 20, 2017 at 04:13:16PM +0000, Wang, Wei W wrote: >> On Wednesday, December 20, 2017 8:26 PM, Matthew Wilcox wrote: >>> unsigned long bit; >>> xb_preload(GFP_KERNEL); >>> xb_set_bit(xb, 700); >>> xb_preload_end(); >>> bit = xb_find_set(xb, ULONG_MAX, 0); >>> assert(bit == 700); >> This above test will result in "!node with bitmap !=NULL", and it goes to the regular "if (bitmap)" path, which finds 700. >> >> A better test would be >> ... >> xb_set_bit(xb, 700); >> assert(xb_find_...

Since virtio-ccw doesn't work with accessing to the config registers inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. Wei Wang (2): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func drivers/virtio/virtio_balloon.c | 59

...> + unsigned long ebit = bit + 2; >> + unsigned long tmp = (unsigned long)bitmap; >> + >> + nbits = min(end - start + 1, BITS_PER_LONG - ebit); >> + >> + if (ebit >= BITS_PER_LONG) > What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ? Thanks. I also improved the test case for this. I plan to change the implementation a little bit to avoid such overflow (has passed the test case that I have, just post out for another set of eyes): { ... unsigned long idx = start / IDA_BITMAP_BITS; u...

...1: xbitmap >> - add __rcu to "void **slot"; >> - remove the exceptional path. >> 2) patch 3: xbitmap >> - DeveloperNotes: add an item to comment that the current bit range >> related APIs operating on extremely large ranges (e.g. >> [0, ULONG_MAX)) will take too long time. This can be optimized in >> the future. >> - remove the exceptional path; >> - remove xb_preload_and_set(); >> - reimplement xb_clear_bit_range to make its usage close to >> bitmap_clear; >> - rename xb_find_next_set_bit to xb...

...1: xbitmap >> - add __rcu to "void **slot"; >> - remove the exceptional path. >> 2) patch 3: xbitmap >> - DeveloperNotes: add an item to comment that the current bit range >> related APIs operating on extremely large ranges (e.g. >> [0, ULONG_MAX)) will take too long time. This can be optimized in >> the future. >> - remove the exceptional path; >> - remove xb_preload_and_set(); >> - reimplement xb_clear_bit_range to make its usage close to >> bitmap_clear; >> - rename xb_find_next_set_bit to xb...

Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (2): virtio-balloon: tweak

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the host. The second feature can be used to accelerate live migration of VMs. Here are some details: Live