Thread (47 messages) 47 messages, 9 authors, 2024-03-07

Re: [PATCH] net: raise RCU qs after each threaded NAPI poll

From: Jakub Kicinski <kuba@kernel.org>
Date: 2024-02-28 14:43:45
Also in: bpf, lkml, rcu

On Tue, 27 Feb 2024 20:42:24 -0800 Paul E. McKenney wrote:
On Tue, Feb 27, 2024 at 07:10:01PM -0800, Jakub Kicinski wrote:
quoted
On Tue, 27 Feb 2024 10:32:22 -0800 Paul E. McKenney wrote:  
quoted
The theory is that PREEMPT_RCU kernels have preemption, and get their
quiescent states that way.  
But that doesn't work well enough?

Assuming that's the case why don't we add it with the inverse ifdef
condition next to the cond_resched() which follows a few lines down?

			skb_defer_free_flush(sd);
+
+			if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+				rcu_softirq_qs();
+
			local_bh_enable();

			if (!repoll)
				break;

			cond_resched();
		}

We won't repoll majority of the time.  
I am not completely clear on what you are proposing, but one complication
is that We need preemption disabled across calls to rcu_softirq_qs()
and we cannot have preemption disabled across calls to cond_resched().
I was thinking of using rcu_all_qs(), like cond_resched() does.
Not sure how it compares in terms of functionality and cost.
Another complication is that although CONFIG_PREEMPT_RT kernels are
built with CONFIG_PREEMPT_RCU, the reverse is not always the case.
And if we are not repolling, don't we have a high probability of doing
a voluntary context when we reach napi_thread_wait() at the beginning
of that loop?
Very much so, which is why adding the cost of rcu_softirq_qs()
for every NAPI run feels like an overkill.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help