Re: [RFC] Limit the size of the IPV4 route hash.

Robin Holt [off-list ref] wrote:

I realize I have a special case which highlighted the problem.  My case
 shows that not putting an upper limit or at least a drastically aggressive
 non-linear growth cap does cause issues.  For the really large system,
 we were seeing a size of 512MB for the hash which was limited because
 that was the largest amount of memory available on a single node.  I can
 not ever imagine this being a reasonable limit.  Not with 512 cpus and
 1024 network adapters could I envision that this level of hashing would
 actually be advantageous given all the other lock contention that will
 be seen.

Half a gig for the hashtable does seems a bit nutty.

 Can we agree that a linear calculation based on num_physpages is probably
 not the best algorithm.  If so, should we make it a linear to a limit or
 a logarithmically decreasing size to a limit?  How do we determine that
 limit point?

An initial default of N + M * log2(num_physpages) would probably give a
saner result.

The big risk is that someone has a too-small table for some specific
application and their machine runs more slowly than it should, but they
never notice.  I wonder if it would be possible to put a little once-only
printk into the routing code: "warning route-cache chain exceeded 100
entries: consider using the rhash_entries boot option".