[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b362ccc-fa86-404c-ab58-15370cef7240@paulmck-laptop>
Date: Wed, 24 Sep 2025 01:20:41 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: rcu@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Kernel Team <kernel-team@...a.com>,
Steven Rostedt <rostedt@...dmis.org>,
Andrii Nakryiko <andrii@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH 0/34] Implement RCU Tasks Trace in terms of SRCU-fast and
optimize
On Wed, Sep 24, 2025 at 09:49:23AM +0200, Alexei Starovoitov wrote:
> On Tue, Sep 23, 2025 at 4:21 PM Paul E. McKenney <paulmck@...nel.org> wrote:
> >
> > Hello!
> >
> > This series re-implements RCU Tasks Trace in terms of SRCU-fast,
> > reducing the size of the Linux-kernel RCU implementation by several
> > hundred lines of code. It also removes a conditional branch from the
> > srcu_read_lock_fast() implementation in order to make SRCU-fast a
> > bit more fastpath-friendly. The patches are as follows:
> >
> > 1. Re-implement RCU Tasks Trace in terms of SRCU-fast.
> >
> > 2. Remove unused ->trc_ipi_to_cpu and ->trc_blkd_cpu from
> > task_struct.
> >
> > 3. Remove ->trc_blkd_node from task_struct.
> >
> > 4. Remove ->trc_holdout_list from task_struct.
> >
> > 5. Remove rcu_tasks_trace_qs() and the functions that it calls.
> >
> > 6. context_tracking: Remove
> > rcu_task_trace_heavyweight_{enter,exit}().
> >
> > 7. Remove ->trc_reader_special from task_struct.
> >
> > 8. Remove now-empty RCU Tasks Trace functions and calls to them.
> >
> > 9. Remove unused rcu_tasks_trace_lazy_ms and trc_stall_chk_rdr
> > struct.
> >
> > 10. Remove now-empty show_rcu_tasks_trace_gp_kthread() function.
> >
> > 11. Remove now-empty rcu_tasks_trace_get_gp_data() function.
> >
> > 12. Remove now-empty rcu_tasks_trace_torture_stats_print() function.
> >
> > 13. Remove now-empty get_rcu_tasks_trace_gp_kthread() function.
> >
> > 14. Move rcu_tasks_trace_srcu_struct out of #ifdef
> > CONFIG_TASKS_RCU_GENERIC.
> >
> > 15. Add noinstr-fast rcu_read_{,un}lock_tasks_trace() APIs.
> >
> > 16. Remove now-unused rcu_task_ipi_delay and TASKS_TRACE_RCU_READ_MB.
> >
> > 17. Create a DEFINE_SRCU_FAST().
> >
> > 18. Use smp_mb() only when necessary in RCU Tasks Trace readers.
> >
> > 19. Update Requirements.rst for RCU Tasks Trace.
> >
> > 20. Deprecate rcu_read_{,un}lock_trace().
> >
> > 21. Mark diagnostic functions as notrace.
> >
> > 22. Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast.
> >
> > 23. Create an srcu_expedite_current() function.
> >
> > 24. Test srcu_expedite_current().
> >
> > 25. Create an rcu_tasks_trace_expedite_current() function.
> >
> > 26. Test rcu_tasks_trace_expedite_current().
> >
> > 27. Make DEFINE_SRCU_FAST() available to modules.
> >
> > 28. Make SRCU-fast available to heap srcu_struct structures.
> >
> > 29. Make grace-period determination use ssp->srcu_reader_flavor.
> >
> > 30. Exercise DEFINE_STATIC_SRCU_FAST() and init_srcu_struct_fast().
> >
> > 31. Exercise DEFINE_STATIC_SRCU_FAST() and init_srcu_struct_fast().
> >
> > 32. Require special srcu_struct define/init for SRCU-fast readers.
> >
> > 33. Make SRCU-fast readers enforce use of SRCU-fast definition/init.
> >
> > 34. Update for SRCU-fast definitions and initialization.
>
> Maybe it's just me, but the patch set is too fine grained.
> These 34 patches could be squashed into a handful for better
> review. All these steps: add smp_mb(), make it conditional,
> make it more conditional, remove one field,
> remove another field is a distraction from actual logic at the end.
Fair enough!
I was quite distracted while doing this work, so did it in baby steps to
avoid having to do any sort of complex debugging. My plan is to continue
testing it, and if the tests continue passing, restructure the patch
series, then send v2. You are quite right, and I will (for example)
consolidate the "Remove" patches. And at that point, the "squash"
feature of "git rebase" will be my friend. ;-)
Thanx, Paul
Powered by blists - more mailing lists