summaryrefslogtreecommitdiff
path: root/Documentation/filesystems/proc.txt
diff options
context:
space:
mode:
authorEric Dumazet <dada1@cosmosbay.com>2008-01-31 17:05:09 -0800
committerDavid S. Miller <davem@davemloft.net>2008-01-31 19:28:27 -0800
commit29e75252da20f3ab9e132c68c9aed156b87beae6 (patch)
treeaffd152c959eede937b50f6054a303a388a88545 /Documentation/filesystems/proc.txt
parent174ce0483198b9dffd712fdd7d53635954fddffe (diff)
[IPV4] route cache: Introduce rt_genid for smooth cache invalidation
Current ip route cache implementation is not suited to large caches. We can consume a lot of CPU when cache must be invalidated, since we currently need to evict all cache entries, and this eviction is sometimes asynchronous. min_delay & max_delay can somewhat control this asynchronism behavior, but whole thing is a kludge, regularly triggering infamous soft lockup messages. When entries are still in use, this also consumes a lot of ram, filling dst_garbage.list. A better scheme is to use a generation identifier on each entry, so that cache invalidation can be performed by changing the table identifier, without having to scan all entries. No more delayed flushing, no more stalling when secret_interval expires. Invalidated entries will then be freed at GC time (controled by ip_rt_gc_timeout or stress), or when an invalidated entry is found in a chain when an insert is done. Thus we keep a normal equilibrium. This patch : - renames rt_hash_rnd to rt_genid (and makes it an atomic_t) - Adds a new rt_genid field to 'struct rtable' (filling a hole on 64bit) - Checks entry->rt_genid at appropriate places :
Diffstat (limited to 'Documentation/filesystems/proc.txt')
-rw-r--r--Documentation/filesystems/proc.txt5
1 files changed, 0 insertions, 5 deletions
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 4413a2d4646f..11fe51c036bf 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1919,11 +1919,6 @@ max_size
Maximum size of the routing cache. Old entries will be purged once the cache
reached has this size.
-max_delay, min_delay
---------------------
-
-Delays for flushing the routing cache.
-
redirect_load, redirect_number
------------------------------