On Wed, 15 Mar 2023 18:08:19 -0400 Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > I am doubtful there may be a future where it does not sleep. Why? > Because you need an rcu_head *somewhere*. Unlike with debubojects, > which involves a lock-free per-CPU pool and a locked global pool, and > has the liberty to shutdown if it runs out of objects -- in RCU code > it doesn't have that liberty and it has to just keep working. The > kfree_rcu code does have pools of rcu_head as well, but that is not > thought to be enough to prevent OOM when memory needs to be given > back. AFAIK -- the synchronize_rcu() in there is a last resort and > undesirable (supposed to happen only when running out of > objects/memory). And everything you said above is still implementation, and the user of kvfree_rcu() doesn't care. The only thing different about the two cases is that one is headless. > > Also "mightsleep" means just that -- *might*. That covers the fact > that sleeping may not happen ;-). Yes, and even though you are doubtful of it not ever having a non-sleep implementation, there is still a chance that there might be something someday. > > This is just my opinion and I will defer to Uladzislau, Paul and you > on how to proceed. Another option is "cansleep" which has the same > number of characters as headless. I don't believe expecting users to > read comments is practical, since we did already have comments and > there was a bug in the usage that triggered this whole series. The point of "headless" is that is the rational for this version of kvfree_rcu(). It doesn't have a head. That's an API name that users care about. Why not call it kvfree_rcu_alloc() ? It allocates right? We have might_sleep() in lots of places. In fact, the default is things might sleep. We don't need to call it out. That's what the might_sleep() call is for. Usually it's the non sleep version that is special. We could call the normal kvfree_rcu() "kvfree_rcu_inatomic()" ;-) But I guess that would be a bigger change. -- Steve
