2009-03-31 21:02:44

by Greg Banks

[permalink] [raw]
Subject: [patch 14/29] knfsd: better hashing in the reply cache

Improve the hash function to handle clients which increment the XID
in the unexpected byte order, by folding down the top bits of the XID.

Signed-off-by: Greg Banks <[email protected]>
---

fs/nfsd/nfscache.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

Index: bfields/fs/nfsd/nfscache.c
===================================================================
--- bfields.orig/fs/nfsd/nfscache.c
+++ bfields/fs/nfsd/nfscache.c
@@ -35,12 +35,15 @@ static struct list_head lru_head;
static int cache_disabled = 1;

/*
- * Calculate the hash index from an XID.
+ * Calculate the hash index from an XID. Note, some clients increment
+ * their XIDs in host order, which can result in all the variation being
+ * in the top bits we see here. So we fold those bits down.
*/
static inline u32 request_hash(u32 xid)
{
u32 h = xid;
h ^= (xid >> 24);
+ h ^= ((xid & 0xff0000) >> 8);
return h & (HASHSIZE-1);
}


--
Greg


2009-05-08 22:01:45

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [patch 14/29] knfsd: better hashing in the reply cache

On Wed, Apr 01, 2009 at 07:28:14AM +1100, Greg Banks wrote:
> Improve the hash function to handle clients which increment the XID
> in the unexpected byte order, by folding down the top bits of the XID.

I'm confused; maybe my arithemtic's wrong, but:

>
> Signed-off-by: Greg Banks <[email protected]>
> ---
>
> fs/nfsd/nfscache.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Index: bfields/fs/nfsd/nfscache.c
> ===================================================================
> --- bfields.orig/fs/nfsd/nfscache.c
> +++ bfields/fs/nfsd/nfscache.c
> @@ -35,12 +35,15 @@ static struct list_head lru_head;
> static int cache_disabled = 1;
>
> /*
> - * Calculate the hash index from an XID.
> + * Calculate the hash index from an XID. Note, some clients increment
> + * their XIDs in host order, which can result in all the variation being
> + * in the top bits we see here. So we fold those bits down.
> */
> static inline u32 request_hash(u32 xid)
> {
> u32 h = xid;
> h ^= (xid >> 24);

This xor's the highest 8 bits into the lowest 8 bits; so the
higest-order bits are already being "folded down".

> + h ^= ((xid & 0xff0000) >> 8);

This just folds those same bits down into the order 16-23 bits. Does
that help?

> return h & (HASHSIZE-1);

Especially when we're only taking the bottom few (6, currently) bits
anyway?

--b.

> }
>
>
> --
> Greg