[lttng-dev] Composition of objects and call_rcu() inside helper thread

[Jérémie Galarneau]

On Mon, Dec 7, 2015 at 10:09 AM, Eugene Ivanov
<Eugene.Ivanov at orc-group.com> wrote:
> Hi,
>
> I have rculfhash which contains objects with rculfhashes. When I destruct “big” map it uses call_rcu() for every item. When internal hashes are destructed they use call_cu() too. It seems that to wait until everything is destructed I need two barriers at the end of the big hash destructor. But how can someone handle deeper hierarchy? Is there any way to determine that it is helper thread to not use call_rcu() and destruct everything in place?
>

Hi Eugene,

We actually encountered a similar problem in lttng-tools. Following a
similar pattern, some objects' "tear down" functions were pushing new
callbacks using call_rcu(), leading to the "chaining" of rcu
callbacks.

This had the unfortunate effect of preventing us from tracking memory
leaks; we could not assume that all memory would have been reclaimed
after the rcu_barrier() done at the application's exit since new
deallocation callbacks could have been "pushed" after that barrier.

We worked around the problem by imposing a strict "no rcu chaining"
design rule, but that's easier said than done :-).

I'm not sure what you are trying to guarantee in your specific case,
but if you are in a similar situation, you could insert a number of
barriers that matches the maximal amount of nesting you expect. Of
course, that's prone to breakage as the code change and/or may be
unbounded.

More likely, you'll want to use synchronize_rcu() to reach a grace
period, free the object, and forego using the call_rcu() mechanism.

In our case, a "finalizing" rcu_barrier() that only returns when the
call_rcu queue is emptied would be really useful. It's on my wishlist,
but I have no idea if the current call_rcu() design can offer such a
guarantee.

TL;DR: synchronize_rcu() is probably what you are looking for.

Jérémie

>
> Best regards,
> Eugene Ivanov
>
>
>
>
> ________________________________
>
> This e-mail is confidential and may contain legally privileged information. It is intended only for the addressees. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system.
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com