Thread (42 messages) 42 messages, 6 authors, 18d ago

Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines

flat view

From: Josef Bacik <josef@toxicpanda.com>
Date: 2026-09-22 15:43:05
Also in: bpf, linux-arm-kernel, lkml, rcu

On Thu, 17 Sep 2026 22:20:17 +0200, Frederic Weisbecker wrote:
quoted
+	lockdep_assert_irqs_disabled();
+	WRITE_ONCE(t->rcu_tasks_irq_ip, ip);
+	t->rcu_tasks_exit_cpu = smp_processor_id();
+	raw_spin_lock_rcu_node(rtpcp);
+	list_add(&t->rcu_tasks_exit_list, &rtpcp->rtp_exit_list);
+	raw_spin_unlock_rcu_node(rtpcp);
I don't think we can do that. This is too much unconditional overhead
on the hot preemption path. rcu_tasks_trampoline_text() should be
a condition here.
Sorry, I missed this one before sending v4/v5. Agreed, and it is gone
for v6: the hook is now just the WRITE_ONCE() of the IP plus the
rcu_tasks_trampoline_text() check, and the exit side a single store.

The IP store itself has to stay unconditional because of the kprobe
jump optimizer: its window is ordinary text, so a task parked there
before the optimizer decided to patch was not "trampoline text" when it
was preempted, and the optimizer needs to find it afterwards.
And do we really need to maintain both lists? I understand that they
have different purposes.
[...]
Can the latter replace the former?
With the above there is only the holdout list left. The optimizer's
rcu_tasks_wait_irq_preempted() now does what classic does for its scan:
walk the task list plus the per-CPU exit lists (exit_tasks_rcu_start()
and friends stay shared between the two flavors for that), checking each
task's recorded IP. That is a slow path that only kprobe optimization
hits.

And thanks for picking up the core-RCU follow-on.

Josef
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help