Re: [lttng-dev] [RFC] Deprecating RCU signal flavor

On 8/23/23 10:47, Paul E. McKenney wrote:
> On Mon, Aug 21, 2023 at 11:43:32AM -0400, Mathieu Desnoyers wrote:
>> On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
>>> On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
>>>>
>>>> After discussing it with Mathieu, we agree on the following 3 phases for
>>>> deprecating the signal flavor:
>>>>
>>>>    1) liburcu-signal will be implemented in term of liburcu-mb. The only
>>>>    difference between the two flavors will be the public header files,
>>>>    linked symbols and library name.  Note that this add a regression in
>>>>    term of performance, since the implementation of liburcu-mb adds memory
>>>>    barriers on the reader side which are not present in the original
>>>>    liburcu-signal implementation.
>>>>
>>>>    2) Adding the deprecated attribute to every public functions exposed by
>>>>    the liburcu-signal flavor.  At this point, tests for liburcu-signal
>>>>    will also be removed from the project.  There will be no more support
>>>>    for this flavor.
>>>>
>>>>    3) Removing the liburcu-signal flavor completely from the project.
>>>>
>>>> Finally, here is a tentative versions release of mine for each phase:
>>>>
>>>>    1) 0.15.0 [October 2023] (also TSAN support yay!)
>>>>
>>>>    2) 0.15.1
>>>>
>>>>    3) 0.16.0 || 1.0.0 (maybe a major bump since this is an API breaking
>>>>    change)
>>>
>>> There is a distinction between the version number of the liburcu project
>>> (0.14) and the ABI soname for the shared objects. We may be able to do
>>> step (3) without going to 1.0.0 (I don't see removal of the urcu-signal
>>> flavor a strong enough motivation for hitting 1.0.0 yet).
>>>
>>> Technically speaking, given that we would be removing the entire
>>> liburcu-signal.so shared object, we would not be changing _symbols_
>>> within an existing shared object, therefore I'm not even sure we need to
>>> bump the soname for all the other remaining shared objects.
>>
>> So after merging this commit:
>>
>>      Phase 1 of deprecating liburcu-signal
>>      The first phase of liburcu-signal deprecation consists of implementing
>>      it in term of liburcu-mb. In other words, liburcu-signal is identical to
>>      liburcu-mb at the exception of the function symbols and public header
>>      files.
>>      This is done by:
>>        1) Removing the RCU_SIGNAL specific code in urcu.c
>>        2) Making the RCU_MB specific code also specific to RCU_SIGNAL in
>>        urcu.c
>>        3) Rewriting _urcu_signal_read_unlock_update_and_wakeup to use a
>>        atomic store with CMM_SEQ_CST instead of a store CMM_RELAXED with
>>        cmm_barrier() around it. We could keep the explicit barriers, but that
>>        would require to add some cmm_annotate annotations. Therefore, to be
>>        less intrusive in a public header file, simply use the CMM_SEQ_CST
>>        like for the mb flavor.
>>
>> I notice that an application previously built against urcu-signal with
>> _LGPL_SOURCE defined would have to be rebuilt, which would require a
>> soname bump of urcu-signal.
>>
>> So considering that this phase 1 is not really a "drop in" replacement,
>> I favor removing the urcu-signal flavor entirely before the next release.
>>
>> Thoughts ?
> 
> The replacement is liburcu-mb, correct?

After merging this "phase 1" of the removal, I noticed that we would need
to require applications built with _LGPL_SOURCE defined and using
liburcu-signal to be rebuilt, which would require a major library soname
bump, which I would prefer to avoid unless necessary.

Therefore, I went ahead and pushed additional commits in the master branch
which completely remove liburcu-signal from the tree. Therefore, the next
release of liburcu will not have the liburcu-signal header files nor its
library shared objects.

> 
> I will need to change perfbook, but that should be an easy change,
> plus sys_membarrier() is widely available by now.

Users of liburcu-signal would be expected to migrate to liburcu-memb, which
relies on membarrier to achieve similar performance, but with lower-overhead
grace periods.

Thanks,

Mathieu





-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

_______________________________________________
lttng-dev mailing list
[email protected]
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev