Felix Huettner <[email protected]> writes:
> Previously we slept for a minimum of 200ms after each cleaning run, even
> if we did clean the majority of entries. This originally came from the
> requirement that we need to take the whole conntrack lock to cleanup
> connections and are therefor limited in the progress we can still make
> when inserting.
>
> However with the now implemented locks per zone and the batching this is
> no longer needed. In addition before we could do partion zone cleanings
> we always cleaned a full zone. This meant that a single high load zone
> would still be cleaned quite fast.
>
> Signed-off-by: Felix Huettner <[email protected]>
> ---
> lib/conntrack.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
[...]
> @@ -1618,6 +1621,16 @@ conntrack_clean(struct conntrack *ct, long long now)
> " entries in %lld msec", total_cleaned, count,
> time_msec() - now);
>
> + /* If we did clean more than 10% of our connection limit we assume that
> + * if we would continue we would also find a lot of connections to clean.
> + * In this case we want to rather continue immediately to ensure we get
> + * the connections removed in a high load situation. */
> + if (total_cleaned >= (clean_end / 10)) {
I think we should also add some documentation for the user as well, in
case they see some higher CPU load. Just a section in the NEWS entry
about the 10$ of total conn clean limit. Perhaps we should also add a
COVERAGE_ counter that tells we hit this 'big exhaustion' state. That
way, if an operator sees high CPU, they have something to look at and
rule in/out the ct cleanup mechanism.
WDYT?
> + next_wakeup = 0;
> + } else {
> + next_wakeup = MIN(next_wakeup, min_expiration);
> + }
> +
> return next_wakeup;
> }
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
