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 <gnb@xxxxxxx> > --- > > 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 -- 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