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