----- On Aug 19, 2021, at 8:42 PM, rostedt rostedt@xxxxxxxxxxx wrote:
> On Thu, 19 Aug 2021 17:09:33 -0400
> Steven Rostedt <rostedt@xxxxxxxxxxx> 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
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
