[lttng-dev] [RFC PATCH liburcu 0/2] Remove RCU requirements on hash table destroy
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Tue Jun 6 18:07:36 UTC 2017
----- On Jun 5, 2017, at 6:56 PM, Paul E. McKenney paulmck at linux.vnet.ibm.com wrote:
> On Tue, May 30, 2017 at 05:10:18PM -0400, Mathieu Desnoyers wrote:
>> The RCU lock-free hash table currently requires that the destroy
>> function should not be called from within RCU read-side critical
>> sections. This is caused by the lazy resize, which uses the call_rcu
>> worker thread, even though all it really needs is a workqueue/worker
>> thread scheme.
>>
>> Implement an internal workqueue API in liburcu, and use it instead of
>> call_rcu in rculfhash to overcome this limitation.
>
> Took a quick look, and it appears plausible.
>
> Some opportunity to share CPU-affinity code between this and the
> call_rcu() code, FWIW.
Given that I plan to reimplement the call_rcu code using this new
internal workqueue API, I don't think it is useful to try to lift
out the duplicated code between call_rcu and workqueue. When call_rcu
is reimplemented, the duplicated cpu affinity code will vanish.
> Two of the system-call stubs look to be identical
> other than the system call (EINTR checks and soforth), but I am not sure
> that it is worth combining them.
Are you talking about the futex wait/wakeup ? If so, would the
attached patch that combine those work for you ? I noticed that
even the error handling is identical.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 3972 bytes
Desc: not available
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20170606/06cb3e9b/attachment.obj>
More information about the lttng-dev
mailing list