On 9/9/25 11:08, Uladzislau Rezki wrote: > On Mon, Sep 08, 2025 at 02:45:11PM +0200, Vlastimil Babka wrote: >> >> Hm I could not find where that distinction is in the code, can you give a >> hint please. In __kfree_rcu_sheaf() I do only have a GFP_NOWAIT attempt. >> > For PREEMPT_RT a regular spin-lock is an rt-mutex which can sleep. We > made kvfree_rcu() to make it possible to invoke it from non-sleep contexts:
Oh you mean it's not allocating even on !RT so there's no RT-specific code. > CONFIG_PREEMPT_RT > > preempt_disable() or something similar; > kvfree_rcu(); > GFP_NOWAIT - lock rt-mutex > > If GFP_NOWAIT semantic does not access any spin-locks then we are safe > or if it uses raw_spin_locks. It does access spinlocks so it's not safe. Thanks, I didn't realize that aspect of kfree_rcu(). We'll need to solve this before making sheaves enabled everywhere. I don't think the vma or maple tree code would kfree_rcu() vma or maple_node in such a restricted context. But to be safe I'll just disable the kfree rcu sheaves for PREEMPT_RT for now. >> > - call_rcu() can be slow, therefore we do not use it in the kvfree_rcu(). >> >> If call_rcu() is called once per 32 kfree_rcu() filling up the rcu sheaf, is >> it still too slow? >> > You do not know where in a queue this callback lands, in the beginning, > in the end, etc. It is part of generic list which is processed one by > one. It can contain thousands of callbacks. > > If performance is not needed then it is not an issue. But in > kvfree_rcu() we do not use it, because of we want to offload > fast. So IIUC one could call_rcu(obj, some_callback_accessing_obj) and then do a kfree_rcu(obj) and the latter can be processed first? > -- > Uladzislau Rezki
