> you should run the tests. doing a hash across too many buckets ends up > costing performance as well. Yes, I should :=) > you want the list per bucket to not be too long, but you also don't want to > spend more effort and ram on empty buckets. What's the extra effort when you have the ram to spare? A worst you might slightly reduce the cache hit rate. > setting conntrack_max equal to the number of buckets doesn't mean that you > will have one entry in each bucket, it means that you will have a lot of > empty buckets and other buckets with several items in them. Right, but it's more likely to have short bucket lists if you have more hash buckets, given the same number of connections, isn't it? > >The FAQ says though, that one should use odd hash bucket counts, so you > >might want to decrease that by one. > > it's not unusual for simple (i.e. cheap to use) has algorithims to have > pathalogical results for specific sizes. ideally you want the bucket count > to be a prime number, if it's not (for example a even power of 2) you can > get situations where it only puts things in a very small number of buckets. As far as I understand is, the Jenkins Hash used internally in netfilter and other parts of the Linux kernel, isn't just your average text book hash, but something with quite a lot of thought and analysis behind it: => http://www.burtleburtle.net/bob/hash/doobs.html
Attachment:
signature.asc
Description: Digital signature
