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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
