Re: [PATCH net-next] netfilter: conntrack: Reduce cond_resched frequency in gc_worker

[Florian Westphal <fw@strlen.de>]

Li,Rongqing <lirongqing@baidu.com> wrote:

[ CC scheduler experts & drop netfilter maintainers ]

Context: proposed patch
(https://patchwork.ozlabs.org/project/netfilter-devel/patch/20251014115103.2678-1-lirongqing@baidu.com/)
does:

-		cond_resched();
+		if (jiffies - resched_time > msecs_to_jiffies(1)) {
+			cond_resched();
+			resched_time = jiffies;
+		}

... and my knee-jerk reaction was "reject".

But author pointed me at:
commit 271557de7cbfdecb08e89ae1ca74647ceb57224f
xfs: reduce the rate of cond_resched calls inside scrub

So:

Is calling cond_resched() unconditionally while walking hashtable/tree etc.
really discouraged?  I see a truckload of cond_resched() calls in similar
walkers all over networking. I find it hard to believe that conntrack is
somehow special and should call it only once per ms.

If cond_resched() is really so expensive even just for *checking*
(retval 0), then maybe we should only call it for every n-th hash slot?
(every L1_CACHE_BYTES?).

But even in that case it would be good to have a comment or documentation
entry about recommended usage, or better yet, make a variant of
xchk_maybe_relax() available via sched.h...