netdev
[Top] [All Lists]

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

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [6/6]: jenkins hash for neigh
From: Thomas Graf <tgraf@xxxxxxx>
Date: Sun, 26 Sep 2004 13:21:20 +0200
Cc: Harald Welte <laforge@xxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20040925203116.4e6f9b06.davem@davemloft.net>
References: <20040923225158.23c2d502.davem@davemloft.net> <20040924085234.GE3236@sunbeam.de.gnumonks.org> <20040924142702.62a2b23d.davem@davemloft.net> <20040925064406.GL3236@sunbeam.de.gnumonks.org> <20040925005623.2faf8faf.davem@davemloft.net> <20040925090933.GU3236@sunbeam.de.gnumonks.org> <20040925203116.4e6f9b06.davem@davemloft.net>
Sender: netdev-bounce@xxxxxxxxxxx
* David S. Miller <20040925203116.4e6f9b06.davem@xxxxxxxxxxxxx> 2004-09-25 20:31
> 1) Parameterizing neigh_forced_gc() so that it purges say "N"
>    entries each run instead of scanning the entire hash table.
>    Perhaps some fraction of tbl->entries

I'm not familiar with the neighbour code but here's a wild
thought:

Calculate the average number of neigh additions (A) over the last
few minutes. Count the number of additions since the last call
to neigh_forced_gc() (L). Make N depdendant on L, the faster the
list grows the more entries we should check by each run to avoid
the list growing too fast. Calculate a aggresivity factor out
of A and L and remove stale and incomplete entries depending on this
factor. Maybe L needs to be calculate from the last few gc runs.

I don't know if any of this is implemented already or whether
it's possible or not. The basic idea is to figure out unnatural
situations and handle them more aggressively.

<Prev in Thread] Current Thread [Next in Thread>