[lttng-dev] High memory consumption issue on RCU side
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Fri Sep 23 21:59:00 UTC 2016
----- On Sep 22, 2016, at 3:14 PM, Evgeniy Ivanov lolkaantimat at gmail.com wrote:
> Hi all,
>
> I'm investigating high memory usage of my program: RSS varies between
> executions in range 20-50 GB, though it should be determenistic. I've
> found that all the memory is allocated in this stack:
>
> Allocated 17673781248 bytes in 556 allocations
> cds_lfht_alloc_bucket_table3 from liburcu-cds.so.2.0.0
> _do_cds_lfht_resize from liburcu-cds.so.2.0.0
> do_resize_cb from liburcu-cds.so.2.0.0
> call_rcu_thread from liburcu-qsbr.so.2.0.0
> start_thread from libpthread-2.12.so
> clone from libc-2.12.so
>
> According pstack it should be quiescent state. Call thread waits on syscall:
> syscall
> call_rcu_thread
> start_thread
> clone
>
> We use urcu-0.8.7, only rculfhash (QSBR). Is it some kind of leak in
> RCU or any chance I misuse it? What would you recommend to
> troubleshoot the situation?
urcu-qsbr is the fastest flavor of urcu, but it is rather tricky to use well.
Make sure that:
- Each registered thread periodically reach a quiescent state, by:
- Invoking rcu_quiescent_state periodically, and
- Making sure to surround any blocking for relatively large amount of
time by rcu_thread_offline()/rcu_thread_online().
In urcu-qsbr, the "default" state of threads is to be within a RCU read-side.
Therefore, if you omit any of the two advice above, you end up in a situation
where grace periods never complete, and therefore no call_rcu() callbacks can
be processed. This effectively acts like a big memory leak.
Hoping this helps,
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list