Re: [PATCH v7 09/16] SUNRPC/cache: use new hashtable implementation
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: 2012-10-29 12:42:35
Also in:
dm-devel, linux-nfs, lkml, netdev
* Sasha Levin (levinsasha928@gmail.com) wrote:
quoted hunk ↗ jump to hunk
Switch cache to use the new hashtable implementation. This reduces the amount of generic unrelated code in the cache implementation. Signed-off-by: Sasha Levin <redacted> --- net/sunrpc/cache.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c index fc2f7aa..0490546 100644 --- a/net/sunrpc/cache.c +++ b/net/sunrpc/cache.c@@ -28,6 +28,7 @@ #include <linux/workqueue.h> #include <linux/mutex.h> #include <linux/pagemap.h> +#include <linux/hashtable.h> #include <asm/ioctls.h> #include <linux/sunrpc/types.h> #include <linux/sunrpc/cache.h>@@ -524,19 +525,18 @@ EXPORT_SYMBOL_GPL(cache_purge); * it to be revisited when cache info is available */ -#define DFR_HASHSIZE (PAGE_SIZE/sizeof(struct list_head)) -#define DFR_HASH(item) ((((long)item)>>4 ^ (((long)item)>>13)) % DFR_HASHSIZE) +#define DFR_HASH_BITS 9
If we look at a bit of history, mainly commit:
commit 1117449276bb909b029ed0b9ba13f53e4784db9d
Author: NeilBrown [off-list ref]
Date: Thu Aug 12 17:04:08 2010 +1000
sunrpc/cache: change deferred-request hash table to use hlist.
we'll notice that the only reason why the prior DFR_HASHSIZE was using
(PAGE_SIZE/sizeof(struct list_head))
instead of
(PAGE_SIZE/sizeof(struct hlist_head))
is because it has been forgotten in that commit. The intent there is to
make the hash table array fit the page size.
By defining DFR_HASH_BITS arbitrarily to "9", this indeed fulfills this
purpose on architectures with 4kB page size and 64-bit pointers, but not
on some powerpc configurations, and Tile architectures, which have more
exotic 64kB page size, and of course on the far less exotic 32-bit
pointer architectures.
So defining e.g.:
#include <linux/log2.h>
#define DFR_HASH_BITS (PAGE_SHIFT - ilog2(BITS_PER_LONG))
would keep the intended behavior in all cases: use one page for the hash
array.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>