Re: [6/6]: jenkins hash for neigh

[Harald Welte <laforge@gnumonks.org>]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

On Sat, Sep 25, 2004 at 12:56:23AM -0700, David S. Miller wrote:
> > I'll inclue it in my next round of kernel builds and give it
> > some testing.
> 
> Thanks.

Please note that I guess I won't have any results until late Sunday/Monday.

> 4) The controversial/RFC patch, dorking with neigh_forced_gc()
> 
> So let's discuss #4.  It is the first idea I had to combat the
> "problem", but honestly right now I am beginning to think that
> the real solution is to simply remove the INCOMPLETE checks
> altogether.
> 
> Neighbours are a sub-cache of the routing cache.  Therefore when
> a neigh entry has a singular refcount, no routing cache entry
> points to it.  No routing cache entry, we're not sending packets
> to that neighbour any time soon, so there is no reason (especially
> during strong pressure) to hold onto such entries.

I am sure this is valid for IPv4 and IPv6.  How about other users of the
neighbour cache, do they share this assumption?  I have to admit that I
never looked throgh the ATM or 

> Agree or disagree?  Regardless, I'd be interested how effective
> your stress case is with patch #4 and my new suggestion which
> is just to remove the:

I'll do tests with and without INCOMPLETE check. No results until late
Sunday/Monday, as indicated above.

[yes, I noticed your corrected version of diff4]

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]