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 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 *, unsigned long bit, gfp_t); void xbit_clear(struct xbitmap *, unsigned long bit); int __must_check xbit_alloc(struct xbitmap *, unsigned long *bit, gfp_t); int __must_check xbit_fill(struct xbitmap *, unsigned long start, unsigned long nbits, gfp_t); void xbit_zero(struct xbitmap *, unsigned long start, unsigned long nbits); int __must_check xbit_alloc_range(struct xbitmap *, unsigned long *bit, unsigned long nbits, gfp_t); bool xbit_find_clear(struct xbitmap *, unsigned long *start, unsigned long max); bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned long max); (I'm a little sceptical about the API accepting 'max' for the find functions and 'nbits' in the fill/zero/alloc_range functions, but I think that matches how people want to use it, and it matches how bitmap.h works)
On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote:> 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.Another place I saw your comment " 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 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 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 *, unsigned long bit, gfp_t); void xbit_clear(struct > xbitmap *, unsigned long bit); int __must_check xbit_alloc(struct xbitmap *, > unsigned long *bit, gfp_t); > > int __must_check xbit_fill(struct xbitmap *, unsigned long start, > unsigned long nbits, gfp_t); void xbit_zero(struct xbitmap *, > unsigned long start, unsigned long nbits); int __must_check > xbit_alloc_range(struct xbitmap *, unsigned long *bit, > unsigned long nbits, gfp_t); > > bool xbit_find_clear(struct xbitmap *, unsigned long *start, unsigned long > max); bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned > long max); > > (I'm a little sceptical about the API accepting 'max' for the find functions and > 'nbits' in the fill/zero/alloc_range functions, but I think that matches how > people want to use it, and it matches how bitmap.h works)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. Best, Wei
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: > > > 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. > > Another place I saw your comment " 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?Yes, the xb_ implementation requires you to handle your own locking. The xbit_ API that I'm proposing will take care of the locking for you. There's also no preallocation in the API.> We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates no "1" bit is found.I put a replacement 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 I've been considering optimising the memory consumption when an entire 1024-bit chunk is full; instead of keeping a pointer to a 128-byte entry full of ones, store a special value in the radix tree which means "every bit is set". The 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 (which replaces the radix tree) finished first.