On Sat, 25 Sep 2004 08:44:06 +0200
Harald Welte <laforge@xxxxxxxxxxxx> wrote:
> I'll inclue it in my next round of kernel builds and give it
> some testing.
Thanks.
> Do you still want to push this for 2.6.9?
>
> I think I'll defer the 2.4.x backport until we've sorted out the one
> remaining 'starvation due to incomplete' issue.
Yes, and I'll defer the push to 2.6.9 until we conquer that too.
So let's start! :-)
Attached are 4 patches, the first 3 I'm happy with the last
is a major RFC. Here's the breakdown:
1) Remove unnecessary next = NULL assignment noticed earlier today.
2) Tim Gardner's change to smooth out periodic neighbour GC.
3) Fix locking and GFP_* bugs.
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.
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:
(n->nud_state != NUD_INCOMPLETE ||
time_after(jiffies, n->used +
n->parms->retrans_time)
from the neigh_forced_gc() code.
Have at it :-)
diff1
Description: Binary data
diff2
Description: Binary data
diff3
Description: Binary data
diff4
Description: Binary data
|