Robin Holt <holt@sgi.com> 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".

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/