> > > > > > Very good. When does kfree_rcu() and friends move out of kernel/rcu? > > > > > Do you mean to move the whole logic of kfree_rcu() from top to down to mm/? > > I do mean exactly that. > > That was my goal some years back when Rao Shoaib was making the first > attempt along these lines, and it remains my goal. After all, if this > effort is at all successful, the coupling between kfree_rcu() with > slab/slob/slub will become much tighter than that between kfree_rcu() > and RCU. > > There will need to be some additional RCU APIs used by kfree_rcu(), > for example, something to tell RCU how many blocks are awaiting a > grace period. But these are narrow and easily defined APIs. > I also think that k[v]free_rcu() should reside somewhere under "mm/". Currently they are defined as macros under "linux/rcupdate.h". So i am not sure if definitions should stay there or moved also. Implementation of the k[v]free_rcu() is under rcu/tree.c and for tiny variant is under rcutiny.h. It can be moved to the mm/slab_common.c or independent files can be created. I think, mm people should consult what is the best way to go :) Any thoughts on it? Thank you! -- Vlad Rezki
