----- On Aug 19, 2021, at 8:42 PM, rostedt rostedt@goodmis.org wrote:
On Thu, 19 Aug 2021 17:09:33 -0400 Steven Rostedt rostedt@goodmis.org wrote:
Mathieu, seems that the "slow down 10x" patch was able to be backported to 5.10, where as this patch was not. Reason being is that start_poll_synchronize_rcu() was added in 5.13.
I can get this to work if I backport the following RCU patches:
29d2bb94a8a126ce80ffbb433b648b32fdea524e srcu: Provide internal interface to start a Tree SRCU grace period
5358c9fa54b09b5d3d7811b033aa0838c1bbaaf2 srcu: Provide polling interfaces for Tree SRCU grace periods
1a893c711a600ab57526619b56e6f6b7be00956e srcu: Provide internal interface to start a Tiny SRCU grace period
8b5bd67cf6422b63ee100d76d8de8960ca2df7f0 srcu: Provide polling interfaces for Tiny SRCU grace periods
The first three can be cherry-picked without issue. The last one has a small conflict, of:
include/linux/srcutiny.h.rej: --- include/linux/srcutiny.h +++ include/linux/srcutiny.h @@ -16,6 +16,7 @@ struct srcu_struct { short srcu_lock_nesting[2]; /* srcu_read_lock() nesting depth. */ unsigned short srcu_idx; /* Current reader array element in bit 0x2. */
unsigned short srcu_idx_max; /* Furthest future srcu_idx request. */ u8 srcu_gp_running; /* GP workqueue running? */ u8 srcu_gp_waiting; /* GP waiting for readers? */ struct swait_queue_head srcu_wq;Which I just added that line, and everything worked.
Paul, do you have any issues with these four patches getting backported?
Greg, Are you OK with them too?
Once those are backported, this patch can be backported as well, and everything should work. This patch really needs to stay with:
231264d6927f6740af36855a622d0e240be9d94c tracepoint: Fix static call function vs data state mismatch
Otherwise I would say to revert it if this one can't be backported with it.
In my opinion backporting those patches to stable is important, because the tracepoint fix which causes the slowdown is really fixing a correctness issue: it ensures that the kernel does not crash in specific race scenarios.
Indeed the slowdown associated with that patch is quite big on typical use-cases of tracepoint registration/unregistration, so the second fixing the speed regression is also important, and that last fix requires the SRCU backports.
Thanks,
Mathieu