Re: [PATCH V2 1/5] xfsprogs: introduce liburcu support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25 Sep 2021 at 03:21, Eric Sandeen wrote:
> 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.

Yes, rcu_init() gets defined to one of the variants of userspace rcu. Hence
there is no function named rcu_init().

>
> 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()."

Unfortunately, I don't think there is an obvious method to detect if calls to
rcu_[un]register_thread() is missing from any code changes implemented in the
future.

PS: I am no expert at RCU. My knowledge about RCU is limited to what I could
learn by reading articles on the world wide web.

-- 
chandan



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux