[LSF/MM/BPF TOPIC] Changes in RCU over the past few years

[LSF/MM/BPF TOPIC] Changes in RCU over the past few years

[Paul E. McKenney]

Hello!

There have been a number of changes to RCU over the past few years,
including consolidating the update-side RCU-preempt, RCU-sched,
and RCU-bh flavors, the addition of TREE SRCU, non-sleeping polled
grace-period interfaces for RCU and SRCU, and addition of a couple
variants of Tasks RCU.  This topic would include a quick overview of
these changes, with special attention to challenges when back porting to
pre-consolidated-RCU kernels.  Time permitting, it might also be useful
to look at some of the nuances of SLAB_DESTROY_BY_RCU.

This would also be an opportunity to discuss RCU use cases and potential
changes to RCU itself.

						Thanx, Paul

Re: [LSF/MM/BPF TOPIC] Changes in RCU over the past few years

[Chaitanya Kulkarni]

On 3/3/22 19:51, Paul E. McKenney wrote:
> Hello!
> 
> There have been a number of changes to RCU over the past few years,
> including consolidating the update-side RCU-preempt, RCU-sched,
> and RCU-bh flavors, the addition of TREE SRCU, non-sleeping polled
> grace-period interfaces for RCU and SRCU, and addition of a couple
> variants of Tasks RCU.  This topic would include a quick overview of
> these changes, with special attention to challenges when back porting to
> pre-consolidated-RCU kernels.  Time permitting, it might also be useful
> to look at some of the nuances of SLAB_DESTROY_BY_RCU.
> 
> This would also be an opportunity to discuss RCU use cases and potential
> changes to RCU itself.
> 
> 						Thanx, Paul
> 

I'll be very much interested in this topic and I think everyone
non-only mm but fs/storage tracks can also benefit from this.

Perhaps we should add respective mailing list to this thread ?
(linux-block and linux-fsdevel)

-ck

Re: [LSF/MM/BPF TOPIC] Changes in RCU over the past few years

[Paul E. McKenney]

On Mon, Mar 07, 2022 at 03:50:43AM +0000, Chaitanya Kulkarni wrote:
> On 3/3/22 19:51, Paul E. McKenney wrote:
> > Hello!
> > 
> > There have been a number of changes to RCU over the past few years,
> > including consolidating the update-side RCU-preempt, RCU-sched,
> > and RCU-bh flavors, the addition of TREE SRCU, non-sleeping polled
> > grace-period interfaces for RCU and SRCU, and addition of a couple
> > variants of Tasks RCU.  This topic would include a quick overview of
> > these changes, with special attention to challenges when back porting to
> > pre-consolidated-RCU kernels.  Time permitting, it might also be useful
> > to look at some of the nuances of SLAB_DESTROY_BY_RCU.
> > 
> > This would also be an opportunity to discuss RCU use cases and potential
> > changes to RCU itself.
> > 
> > 						Thanx, Paul
> > 
> 
> I'll be very much interested in this topic and I think everyone
> non-only mm but fs/storage tracks can also benefit from this.
> 
> Perhaps we should add respective mailing list to this thread ?
> (linux-block and linux-fsdevel)

Works for me!

							Thanx, Paul

Re: [LSF/MM/BPF TOPIC] Changes in RCU over the past few years

[Chaitanya Kulkarni]

On 3/9/22 13:38, Paul E. McKenney wrote:
> On Mon, Mar 07, 2022 at 03:50:43AM +0000, Chaitanya Kulkarni wrote:
>> On 3/3/22 19:51, Paul E. McKenney wrote:
>>> Hello!
>>>
>>> There have been a number of changes to RCU over the past few years,
>>> including consolidating the update-side RCU-preempt, RCU-sched,
>>> and RCU-bh flavors, the addition of TREE SRCU, non-sleeping polled
>>> grace-period interfaces for RCU and SRCU, and addition of a couple
>>> variants of Tasks RCU.  This topic would include a quick overview of
>>> these changes, with special attention to challenges when back porting to
>>> pre-consolidated-RCU kernels.  Time permitting, it might also be useful
>>> to look at some of the nuances of SLAB_DESTROY_BY_RCU.
>>>
>>> This would also be an opportunity to discuss RCU use cases and potential
>>> changes to RCU itself.
>>>
>>> 						Thanx, Paul
>>>
>>
>> I'll be very much interested in this topic and I think everyone
>> non-only mm but fs/storage tracks can also benefit from this.
>>
>> Perhaps we should add respective mailing list to this thread ?
>> (linux-block and linux-fsdevel)
> 
> Works for me!
> 
> 							Thanx, Paul
> 

adding linux-block, linux-nvme and linux-fsdevel.

-ck