From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dichtel Subject: Re: [PATCH 09/14] netfilter: conntrack: refine gc worker heuristics, redux Date: Fri, 27 Jan 2017 17:51:11 +0100 Message-ID: <09f1081e-ade3-6099-a3c6-b1b912592f54@6wind.com> References: <1485448687-6072-1-git-send-email-pablo@netfilter.org> <1485448687-6072-10-git-send-email-pablo@netfilter.org> Reply-To: nicolas.dichtel@6wind.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: davem@davemloft.net, netdev@vger.kernel.org To: Pablo Neira Ayuso , netfilter-devel@vger.kernel.org Return-path: Received: from mail-wm0-f50.google.com ([74.125.82.50]:35631 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755097AbdA0QvZ (ORCPT ); Fri, 27 Jan 2017 11:51:25 -0500 Received: by mail-wm0-f50.google.com with SMTP id r126so125529723wmr.0 for ; Fri, 27 Jan 2017 08:51:14 -0800 (PST) In-Reply-To: <1485448687-6072-10-git-send-email-pablo@netfilter.org> Sender: netdev-owner@vger.kernel.org List-ID: Le 26/01/2017 à 17:38, Pablo Neira Ayuso a écrit : > From: Florian Westphal > > This further refines the changes made to conntrack gc_worker in > commit e0df8cae6c16 ("netfilter: conntrack: refine gc worker heuristics"). > > The main idea of that change was to reduce the scan interval when evictions > take place. > > However, on the reporters' setup, there are 1-2 million conntrack entries > in total and roughly 8k new (and closing) connections per second. > > In this case we'll always evict at least one entry per gc cycle and scan > interval is always at 1 jiffy because of this test: > > } else if (expired_count) { > gc_work->next_gc_run /= 2U; > next_run = msecs_to_jiffies(1); > > being true almost all the time. > > Given we scan ~10k entries per run its clearly wrong to reduce interval > based on nonzero eviction count, it will only waste cpu cycles since a vast > majorities of conntracks are not timed out. > > Thus only look at the ratio (scanned entries vs. evicted entries) to make > a decision on whether to reduce or not. > > Because evictor is supposed to only kick in when system turns idle after > a busy period, pick a high ratio -- this makes it 50%. We thus keep > the idea of increasing scan rate when its likely that table contains many > expired entries. > > In order to not let timed-out entries hang around for too long > (important when using event logging, in which case we want to timely > destroy events), we now scan the full table within at most > GC_MAX_SCAN_JIFFIES (16 seconds) even in worst-case scenario where all > timed-out entries sit in same slot. > > I tested this with a vm under synflood (with > sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv=3). > > While flood is ongoing, interval now stays at its max rate > (GC_MAX_SCAN_JIFFIES / GC_MAX_BUCKETS_DIV -> 125ms). > > With feedback from Nicolas Dichtel. > > Reported-by: Denys Fedoryshchenko > Cc: Nicolas Dichtel > Fixes: b87a2f9199ea82eaadc ("netfilter: conntrack: add gc worker to remove timed-out entries") > Signed-off-by: Florian Westphal > Tested-by: Nicolas Dichtel > Acked-by: Nicolas Dichtel > Tested-by: Denys Fedoryshchenko > Signed-off-by: Pablo Neira Ayuso Pablo, is it possible to queue this patch (and the previous: 08/14) for the 4.9 stable? Thank you, Nicolas