On 9/24/21 9:09 AM, Chandan Babu R wrote:
From: Dave Chinner <dchinner@xxxxxxxxxx> The upcoming buffer cache rework/kerenl sync-up requires atomic variables. I could use C++11 atomics build into GCC, but they are a pain to work with and shoe-horn into the kernel atomic variable API. Much easier is to introduce a dependency on liburcu - the userspace RCU library. This provides atomic variables that very closely match the kernel atomic variable API, and it provides a very similar memory model and memory barrier support to the kernel. And we get RCU support that has an identical interface to the kernel and works the same way. Hence kernel code written with RCU algorithms and atomic variables will just slot straight into the userspace xfsprogs code without us having to think about whether the lockless algorithms will work in userspace or not. This reduces glue and hoop jumping, and gets us a step closer to having the entire userspace libxfs code MT safe. Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> [chandan.babu@xxxxxxxxxx: Add m4 macros to detect availability of liburcu]
Thanks for fixing that up. I had tried to use rcu_init like Dave originally had, and I like that better in general, but I had trouble with it - I guess maybe it gets redefined based on memory model magic and the actual symbol "rcu_init" maybe isn't available? I didn't dig very much. Also, dumb question from me - how do we know where we need the rcu_[un]register_thread() calls? Will it be obvious if we miss it in the future? "each thread must invoke this function before its first call to rcu_read_lock() or call_rcu()." Thanks, -Eric
