* Sasha Levin (levinsasha928@xxxxxxxxx) wrote:
> 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 <levinsasha928@xxxxxxxxx>
> ---
> 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 <neilb@xxxxxxx>
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 from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
