1. 05 5月, 2008 2 次提交
  2. 29 4月, 2008 1 次提交
  3. 24 4月, 2008 1 次提交
  4. 14 4月, 2008 1 次提交
  5. 10 4月, 2008 4 次提交
  6. 26 3月, 2008 4 次提交
  7. 23 3月, 2008 2 次提交
  8. 06 3月, 2008 1 次提交
  9. 29 2月, 2008 6 次提交
  10. 08 2月, 2008 1 次提交
  11. 01 2月, 2008 2 次提交
    • E
      [IPV4] route cache: Introduce rt_genid for smooth cache invalidation · 29e75252
      Eric Dumazet 提交于
      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 :
      29e75252
    • E
      [NET]: should explicitely initialize atomic_t field in struct dst_ops · e2422970
      Eric Dumazet 提交于
      All but one struct dst_ops static initializations miss explicit
      initialization of entries field.
      
      As this field is atomic_t, we should use ATOMIC_INIT(0), and not
      rely on atomic_t implementation.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2422970
  12. 29 1月, 2008 15 次提交