Re: [PATCH 17/24] GFS2: Use RCU/hlist_bl based hash for quotas

From: Sasha Levin
Date: Wed Jan 22 2014 - 01:06:45 EST


On 01/22/2014 12:32 AM, Paul E. McKenney wrote:
On Mon, Jan 20, 2014 at 12:23:40PM +0000, Steven Whitehouse wrote:
>Prior to this patch, GFS2 kept all the quotas for each
>super block in a single linked list. This is rather slow
>when there are large numbers of quotas.
>
>This patch introduces a hlist_bl based hash table, similar
>to the one used for glocks. The initial look up of the quota
>is now lockless in the case where it is already cached,
>although we still have to take the per quota spinlock in
>order to bump the ref count. Either way though, this is a
>big improvement on what was there before.
>
>The qd_lock and the per super block list is preserved, for
>the time being. However it is intended that since this is no
>longer used for its original role, it should be possible to
>shrink the number of items on that list in due course and
>remove the requirement to take qd_lock in qd_get.
>
>Signed-off-by: Steven Whitehouse<swhiteho@xxxxxxxxxx>
>Cc: Abhijith Das<adas@xxxxxxxxxx>
>Cc: Paul E. McKenney<paulmck@xxxxxxxxxxxxxxxxxx>
Interesting! I thought that Sasha Levin had a hash table in the works,
but I don't see it, so CCing him.

Indeed, there is a hlist based hashtable at include/linux/hashtable.h for couple kernel
versions now. However, there's no hlist_bl one.

If there is a plan on adding a hlist_bl hashtable for whatever reason, it should probably
be done by expanding hashtable.h so that more places that use hlist_bl would benefit from it (yes,
there are couple more places that do hlist_bl hashtable).

Also, do we really want to use hlist_bl here? It doesn't seem like it's being done to conserve on
memory, and that's the only reason it should be used for. Doing a single spinlock per bucket is
much more efficient than using the bit locking scheme that hlist_bl does.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/