Re: [PATCH for-next 3/7] net/mlx4_core: change bitmap allocator to work in round-robin fashion

[Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

On Tuesday 08 May 2012 21:46, Roland Dreier wrote:
> > --- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
> > @@ -124,7 +124,6 @@ void mlx4_bitmap_free_range(struct mlx4_bitmap *bitmap, u32 obj, int cnt)
> >
> >        spin_lock(&bitmap->lock);
> >        bitmap_clear(bitmap->table, obj, cnt);
> > -       bitmap->last = min(bitmap->last, obj);
> >        bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> >                        & bitmap->mask;
> >        bitmap->avail += cnt;
> 
> I think this mostly makes sense, although the explanation doesn't quite
> make sense.
> 
> However I think it would also make sense to get rid of changing the
> bitmap->top value here when freeing.  Then we would really go
> round-robin, and only bump bitmap->top each time we wrap around
> during allocation.
> 
> Does that make sense to you?

It does make sense.  Very good catch!  If we also get rid of the bitmap_top
modification in mlx4_bitmap_free_range(), then it will be a VERY long time
before resource numbers repeat. This can only be a good thing.

You are correct that if we do not immediately re-use resource numbers,
then incrementing bitmap_top is only really needed/desirable per wrap-around of the
bitmap.

-Jack
> 
>  - R.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html