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

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

[Olivier Dion via lttng-dev]

Hi all,

We have the intention of deprecating the urcu-signal flavor in the
future.  We are asking users of URCU for _feedback_ on this before
going any further.

Part of this decision is that we are adding support for TSAN in URCU and
the signal flavor deadlocks with TSAN.  It is also my understanding that
the urcu-signal flavor was historically made as a fallback for system
lacking the membarrier(2) system call.  Nowadays, most systems have
support for that system call, making the urcu-signal an artifact of the
past.

The following is a proposed timeline of events:

  1. Asking for feedback from users of URCU (this message)
  2. Disabling the signal flavor by default and adding --enable-flavor-signal
  3. Removing the signal flavor

-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Duncan Sands via lttng-dev]

Hi Olivier, we (DeepBlueCapital) gave up on urcu-signal a long time ago, due to 
the annoying side effects signals can have.  Nowadays we use membarrier, so 
removing urcu-signal is fine as far as we are concerned.

Best wishes, Duncan.

On 10/05/2023 23:10, Olivier Dion via lttng-dev wrote:
> Hi all,
> 
> We have the intention of deprecating the urcu-signal flavor in the
> future.  We are asking users of URCU for _feedback_ on this before
> going any further.
> 
> Part of this decision is that we are adding support for TSAN in URCU and
> the signal flavor deadlocks with TSAN.  It is also my understanding that
> the urcu-signal flavor was historically made as a fallback for system
> lacking the membarrier(2) system call.  Nowadays, most systems have
> support for that system call, making the urcu-signal an artifact of the
> past.
> 
> The following is a proposed timeline of events:
> 
>    1. Asking for feedback from users of URCU (this message)
>    2. Disabling the signal flavor by default and adding --enable-flavor-signal
>    3. Removing the signal flavor
> 

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Paul E. McKenney via lttng-dev]

On Wed, May 10, 2023 at 05:10:27PM -0400, Olivier Dion wrote:
> Hi all,
> 
> We have the intention of deprecating the urcu-signal flavor in the
> future.  We are asking users of URCU for _feedback_ on this before
> going any further.
> 
> Part of this decision is that we are adding support for TSAN in URCU and
> the signal flavor deadlocks with TSAN.  It is also my understanding that
> the urcu-signal flavor was historically made as a fallback for system
> lacking the membarrier(2) system call.  Nowadays, most systems have
> support for that system call, making the urcu-signal an artifact of the
> past.

No objections here.  I will need to do a little rework of my book, but
I can do that.  ;-)

> The following is a proposed timeline of events:
> 
>   1. Asking for feedback from users of URCU (this message)
>   2. Disabling the signal flavor by default and adding --enable-flavor-signal
>   3. Removing the signal flavor

Makes sense to me!

							Thanx, Paul
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Ondřej Surý via lttng-dev]

Hi,

we (ISC) have no intention of using signal based URCU in BIND 9. Our plan relies on using the QSBR flavor as BIND 9 is internally event-loop based with natural quiescent states.

Ondrej 
--
Ondřej Surý <ondrej@sury.org> (He/Him)

> On 10. 5. 2023, at 23:10, Olivier Dion via lttng-dev <lttng-dev@lists.lttng.org> wrote:
> 
> Hi all,
> 
> We have the intention of deprecating the urcu-signal flavor in the
> future.  We are asking users of URCU for _feedback_ on this before
> going any further.
> 
> Part of this decision is that we are adding support for TSAN in URCU and
> the signal flavor deadlocks with TSAN.  It is also my understanding that
> the urcu-signal flavor was historically made as a fallback for system
> lacking the membarrier(2) system call.  Nowadays, most systems have
> support for that system call, making the urcu-signal an artifact of the
> past.
> 
> The following is a proposed timeline of events:
> 
>  1. Asking for feedback from users of URCU (this message)
>  2. Disabling the signal flavor by default and adding --enable-flavor-signal
>  3. Removing the signal flavor
> 
> -- 
> Olivier Dion
> EfficiOS Inc.
> https://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Olivier Dion via lttng-dev]

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)

-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Mathieu Desnoyers via lttng-dev]

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.

Thanks,

Mathieu


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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Mathieu Desnoyers via lttng-dev]

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 ?

Thanks,

Mathieu


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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Paul E. McKenney via lttng-dev]

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?

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

							Thanx, Paul
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Mathieu Desnoyers via lttng-dev]

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
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev