Re: Re: An interesting performance thing ?

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Dec 15, 2005 at 11:02:22AM +1100, Neil Brown wrote:
> The trouble is that just because inet_lnaof makes the final hash
> better for your mix of clients, that doesn't mean it won't make it
> worse for someone else.  I admit that I cannot provide a like sample
> mix of clients what would be worse with inet_lnaof, but that doesn't
> mean they don't exist.

It strikes me as extremely unlikely that any set of clients would have
good variation in the *high* 13 bits of their IP addresses.

In fact, in the common case the high 13 bits are probably completely
constant.

So for these architectures, the ip address lookup is probably usually
degenerating to a linear search.  Since that lookup has to be performed
on every rpc call, this is likely to be painful.

> But I don't propose submitting it to Linus because - useful as it is -
> it is simply wrong.  We need to fix that hash function, and this clear
> problem is a good motivation to do that.

It'd be worth checking whether other callers may be giving hash_long
32-bit inputs, since they might have similar problems.

--b.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs