search for: xbit_clear

...dled internally to the implementation. I looked at the API some more and found some flaws: - how does xbit_alloc communicate back which bit it allocated? - What if xbit_find_set() is called on a completely empty array with a range of 0, ULONG_MAX -- there's no invalid number to return. - xbit_clear() can't return an error. Neither can xbit_zero(). - Need to add __must_check to various return values to discourage sloppy programming So I modify the proposed API we compete with thusly: bool xbit_test(struct xbitmap *, unsigned long bit); int __must_check xbit_set(struct xbitmap *, uns...

...dled internally to the implementation. I looked at the API some more and found some flaws: - how does xbit_alloc communicate back which bit it allocated? - What if xbit_find_set() is called on a completely empty array with a range of 0, ULONG_MAX -- there's no invalid number to return. - xbit_clear() can't return an error. Neither can xbit_zero(). - Need to add __must_check to various return values to discourage sloppy programming So I modify the proposed API we compete with thusly: bool xbit_test(struct xbitmap *, unsigned long bit); int __must_check xbit_set(struct xbitmap *, uns...

...ement proposal in the next paragraph: bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned long max); Maybe 'start' is the wrong name for that parameter. Let's call it 'bit'. It's both "where to start" and "first bit found". > > - xbit_clear() can't return an error. Neither can xbit_zero(). > > I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? Yes, I think so. My only qualm is that...

...ement proposal in the next paragraph: bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned long max); Maybe 'start' is the wrong name for that parameter. Let's call it 'bit'. It's both "where to start" and "first bit found". > > - xbit_clear() can't return an error. Neither can xbit_zero(). > > I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? Yes, I think so. My only qualm is that...

...> - What if xbit_find_set() is called on a completely empty array with > a range of 0, ULONG_MAX -- there's no invalid number to return. We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates no "1" bit is found. > - xbit_clear() can't return an error. Neither can xbit_zero(). I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? > - Need to add __must_check to various retur...

On 12/18/2017 06:18 AM, Matthew Wilcox wrote: > On Sun, Dec 17, 2017 at 01:47:21PM +0000, Wang, Wei W wrote: >> On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote: >>> On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: >>> - xbit_clear() can't return an error. Neither can xbit_zero(). >> I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"? > Yes, I think so. > > My only qua...

...itmap *xb); int xbit_alloc(struct xbitmap *, unsigned long bit, gfp_t); int xbit_alloc_range(struct xbitmap *, unsigned long start, unsigned long nbits, gfp_t); int xbit_set(struct xbitmap *, unsigned long bit, gfp_t); bool xbit_test(struct xbitmap *, unsigned long bit); int xbit_clear(struct xbitmap *, unsigned long bit); int xbit_zero(struct xbitmap *, unsigned long start, unsigned long nbits); int xbit_fill(struct xbitmap *, unsigned long start, unsigned long nbits, gfp_t); unsigned long xbit_find_clear(struct xbitmap *, unsigned long start,...

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

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