On Tue, Sep 21, 2004 at 08:31:18PM -0700, David S. Miller wrote:
> Ok Harald, I did some snooping around and here is what
> I've come up with.
Thanks for digging into this issue.
> 1) We have 5 or 6 implementations of "walk neighbour hash
> table in sequence", that's rediculious and is the only
> reason that hashtable layout or number of entries is
> even known by code outside of net/core/neighbour.c
> 1.5) tbl->ops->hash() should return the raw hash, the caller
> will do the necessary masking.
> 2) We should size these hash table dynamically, growing them
> at neigh_create() time.
great, that sounds like a scalable approach. I'm looking forward to
reading through the code :)
> 3) If we have a sysctl for this stuff at all, it will be for
> the limit of the hash table growth, but I don't think that
> is necessary given #2
But we will still have the existing sysctls for the garbage collector, I
guess (like gc_thresh*).
And I still want to address the "all complete entries flushed due to
lots of bogus incomplete entires" issue somehow. As stated before, I
have seen this on happen on live systems.
Do you agree that this is an existing problem?
I think just having a certain 'reserve' for complete entries (or a let's
say 80% limit for incomplete ones) should address this issue.
btw: I guess you're implementing this as 2.6.x only patch. Once you're
finished, I'll have to do a 2.4.x backport anyway [for business reasons
*g*]. So don't bother doing that, I'll post the patch here (which
doesn't imply that I want to have it merged mainline).
- Harald Welte <laforge@xxxxxxxxxxxx> http://www.gnumonks.org/
Programming is like sex: One mistake and you have to support it your lifetime
Description: Digital signature