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

[Eugene Ivanov]

Hi Jérémie,

Yes, it was exactly the issue with leak checking. Now I use multiple barriers and everything is good. Thanks!

Best regards,
Eugene Ivanov



> On 08 Dec 2015, at 13:16, Jérémie Galarneau <jeremie.galarneau at efficios.com> wrote:
>
> 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


________________________________

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.