[lttng-dev] real time Userspace RCU

[Mathieu Desnoyers]

----- On Mar 11, 2016, at 6:45 AM, Paul E. McKenney paulmck at linux.vnet.ibm.com wrote:

> On Thu, Mar 10, 2016 at 08:53:05PM +0000, Mathieu Desnoyers wrote:
>> ----- On Mar 10, 2016, at 3:33 PM, Yuxin Ren ryx at gwmail.gwu.edu wrote:
>> 
>> > Thank you for your reply.
>> > 
>> > I want to generally understand how to apply urcu to real time systems.
>> > I know real time system focus on predictability on both timing and
>> > memory consumption.
>> > So how does real time urcu support predictability?
>> > Could you provide me some papers, documents or any materials about any
>> > aspect of real time urcu?
>> 
>> Adding Paul E. McKenney in CC, who may have some thoughts on this
>> topic.
> 
> URCU does timing quite well, given that the read-side primitives each
> execute a fixed sequence of instructions.  Updates using call_rcu()
> can be used to minimize update-side latency, but if you need to bound
> memory overhead, the best way to do that is to make sure that updates
> are not on the critical path, and then use synchronize_rcu() instead
> of call_rcu().  In that case, the total amount of memory waiting for
> reclamation is bounded by the maximum size of an RCU-protected memory
> block times the number of threads.

An intermediate solution if both update throughput and bounded-memory
are required (but the application would not have real-time constraints
on updates) would be to use the defer_rcu() API in liburcu. It amortizes
the cost of synchronize_rcu() over many defer_rcu() calls with a worker
thread, but only up to an upper bound. When the upper bound is reached,
the defer queue call empties the defer queue itself.

Thanks,

Mathieu

> 
> So can you design your application so that updates are off the critical
> path?  If so, you can get both bounded read-side accesses and bounded
> memory footprint.
> 
> This of course assumes that your data structures are simple enough
> that readers don't need to use retry techniques.
> 
> The following info might be helpful:
> 
> http://www2.rdrop.com/users/paulmck/realtime/paper/DetSyncRCU.2009.08.18a.pdf
> http://www2.rdrop.com/users/paulmck/realtime/paper/DetSyncRCU.2009.09.29a.pdf
> 
> http://www2.rdrop.com/users/paulmck/realtime/paper/RTLWS2012occcRT.2012.10.19e.pdf
> 
> It also depends on your timeframe.  Microseconds?  Life is hard.
> Milliseconds?  Care is required, but you have a fair amount of freedom.
> Seconds?  Life is not so hard.  Unless you need to do two seconds of
> computation in one second or some such.  ;-)
> 
>							Thanx, Paul
> 
>> Thanks,
>> 
>> Mathieu
>> 
>> > 
>> > Thanks again!
>> > 
>> > On Thu, Mar 10, 2016 at 1:52 PM, Michel Dagenais
>> > <michel.dagenais at polymtl.ca> wrote:
>> >> Real-time and embedded systems is an important current focus for the LTTng
>> >> toolchain research. Do you have specific needs for userspace RCU?
>> >>
>> >> ----- Mail original -----
>> >>> Hi,
>> >>>
>> >>>  Is there any work or research about Userspace RCU on real time or
>> >>> embedded systems?
>> >>> Any information is welcome.
>> >>>
>> >>> Thanks a lot!
>> >>> Yuxin
>> >>> _______________________________________________
>> >>> lttng-dev mailing list
>> >>> lttng-dev at lists.lttng.org
>> >>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >>>
>> > _______________________________________________
>> > lttng-dev mailing list
>> > lttng-dev at lists.lttng.org
>> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> 
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> http://www.efficios.com

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