----- On Jun 17, 2021, at 6:13 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello, > > Some old topic, see > https://lists.lttng.org/pipermail/lttng-dev/2019-November/029411.html. > (I actually thought this was solved meanwhile). > > With lttng 2.13 liburcu is replicated in lttng-ust so my old custom > hack aint helping. > > Aside from another crude hack, I thought about doing this: > > extern int lttng_ust_urcu_has_sys_membarrier; > int setup() { > lttng_ust_urcu_has_sys_membarrier = 0; > } > > this is obvious possible in my own program, but I don't know if some > lttng daemon would need to update RCU structures in shared memory that > should sync to other processes (and wont do that with sys_membarrier > in case of Xenomai threads)? > > Seems safer to me to hack it out once more... We currently don't have any RCU synchronization across shared memory, and the implementation we have in lttng-ust only tracks threads within the same process, so it would be safe to tweak the lttng-ust-urcu behavior to use membarrier or not based on an environment variable. So I think we could expose a new "--disable-sys-membarrier" configure option to lttng-ust, and maybe add a LTTNG_UST_MEMBARRIER environment variable. This would likely be 2.14 material though. I also notice that lttng-ust 2.13's implementation of RCU still refers to CONFIG_RCU_FORCE_SYS_MEMBARRIER which belongs to liburcu. This is probably something we'll want to fix right away before we release 2.13 final. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
