search for: xbit_alloc

On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > Here's the API I'm looking at right now. The user need take no lock; > the locking (spinlock) is handled 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 va...

On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote: > Here's the API I'm looking at right now. The user need take no lock; > the locking (spinlock) is handled 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 va...

..." The xb_ API requires you to handle your own locking" which seems conflict with the above "the user need take no lock". Doesn't the caller need a lock to avoid concurrent accesses to the ida bitmap? > 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. We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates...

...downside is that we then have to pass GFP flags to xbit_clear() and xbit_zero(), and they can fail. It's not clear to me whether that's a good tradeoff. > Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? > > Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. I'm intending on replacing the xb_ and ida_ implementations with this one. It removes the preload API which makes it easier to use, and it handles the locking for you. But I need to get the XArray (whic...

...downside is that we then have to pass GFP flags to xbit_clear() and xbit_zero(), and they can fail. It's not clear to me whether that's a good tradeoff. > Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? > > Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. I'm intending on replacing the xb_ and ida_ implementations with this one. It removes the preload API which makes it easier to use, and it handles the locking for you. But I need to get the XArray (whic...

...map to see if all other bits are set, if so, it can free the ida_bitmap. I think this extra scanning of the ida_bitmap would add a lot overhead. > >> Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? >> >> Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. > I'm intending on replacing the xb_ and ida_ implementations with this one. > It removes the preload API which makes it easier to use, and it handles > the locking for you. > > But I need...

...code size). If you can replace the IDR, you get to count that savings against the cost of your implementation. Here's the API I'm looking at right now. The user need take no lock; the locking (spinlock) is handled internally to the implementation. void xbit_init(struct xbitmap *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...

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