On Thu, 2016-08-25 at 15:33 +0200, Florian Westphal wrote: > Conntrack gc worker to evict stale entries. > > GC happens once every 5 seconds, but we only scan at most 1/64th of the > table (and not more than 8k) buckets to avoid hogging cpu. > > This means that a complete scan of the table will take several minutes > of wall-clock time. > > Considering that the gc run will never have to evict any entries > during normal operation because those will happen from packet path > this should be fine. > > We only need gc to make sure userspace (conntrack event listeners) > eventually learn of the timeout, and for resource reclaim in case the > system becomes idle. > > We do not disable BH and cond_resched for every bucket so this should > not introduce noticeable latencies either. > > A followup patch will add a small change to speed up GC for the extreme > case where most entries are timed out on an otherwise idle system. > > v2: Use cond_resched_rcu_qs & add comment wrt. missing restart on > nulls value change in gc worker, suggested by Eric Dumazet. > > v3: don't call cancel_delayed_work_sync twice (again, Eric). > > Signed-off-by: Florian Westphal <fw@xxxxxxxxx> > --- > net/netfilter/nf_conntrack_core.c | 76 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 76 insertions(+) Acked-by: Eric Dumazet <edumazet@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
