| 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@xxxxxxxxxxxxx> |
| References: | <20040923225158.23c2d502.davem@xxxxxxxxxxxxx> <20040924085234.GE3236@xxxxxxxxxxxxxxxxxxxxxxx> <20040924142702.62a2b23d.davem@xxxxxxxxxxxxx> <20040925064406.GL3236@xxxxxxxxxxxxxxxxxxxxxxx> <20040925005623.2faf8faf.davem@xxxxxxxxxxxxx> <20040925090933.GU3236@xxxxxxxxxxxxxxxxxxxxxxx> <20040925203116.4e6f9b06.davem@xxxxxxxxxxxxx> |
| 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. |
| Previous by Date: | Re: [IPv4]: More fib_alias insertion fixes, Julian Anastasov |
|---|---|
| Next by Date: | Re: [IPv4]: More fib_alias insertion fixes, Herbert Xu |
| Previous by Thread: | Re: [6/6]: jenkins hash for neigh, David S. Miller |
| Next by Thread: | Re: [6/6]: jenkins hash for neigh, Harald Welte |
| Indexes: | [Date] [Thread] [Top] [All Lists] |