On Fri, Oct 14, 2016 at 12:37:26PM +0200, Florian Westphal wrote:
Nicolas Dichtel [off-list ref] wrote:
quoted
Le 13/10/2016 à 22:43, Florian Westphal a écrit :
[...]
quoted
quoted
(Or cause too many useless scans)
Another idea worth trying might be to get rid of the max cap and
instead break early in case too many jiffies expired.
I don't want to add sysctl knobs for this unless absolutely needed; its already
possible to 'force' eviction cycle by running 'conntrack -L'.
Sure, but this is not a "real" solution, just a workaround.
We need to find a way to deliver conntrack deletion events in a reasonable
delay, whatever the traffic on the machine is.
Agree, but that depends on what 'reasonable' means and what kind of
uneeded cpu churn we're willing to add.
We can add a sysctl for this but we should use a low default to not do
too much unneeded work.
So what about your original patch, but only add
nf_conntrack_gc_interval
(and also add instant-resched in case entire budget was consumed)?
I would prefer not to expose sysctl knobs, if we don't really know
what good default values are good, then we cannot expect our users to
know this for us.
I would go tune this in a way that this resembles to the previous
behaviour.