----- On Jun 5, 2017, at 6:56 PM, Paul E. McKenney [email protected] 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
patch
Description: Binary data
_______________________________________________ lttng-dev mailing list [email protected] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
