On Fri, Aug 14, 2020 at 12:06:19AM +0200, peterz@xxxxxxxxxxxxx wrote: > On Thu, Aug 13, 2020 at 11:52:57AM -0700, Paul E. McKenney wrote: > > On Thu, Aug 13, 2020 at 08:26:18PM +0200, peterz@xxxxxxxxxxxxx wrote: > > > > I thought the rule was: > > > > > > - No allocators (alloc/free) inside raw_spinlock_t, full-stop. > > > > > > Why are we trying to craft an exception? > > > > So that we can reduce post-grace-period cache misses by a factor of > > eight when invoking RCU callbacks. This reduction in cache misses also > > makes it more difficult to overrun RCU with floods of either call_rcu() > > or kfree_rcu() invocations. > > > > The idea is to allocate page-sized arrays of pointers so that the callback > > invocation can sequence through the array instead of walking a linked > > list, hence the reduction in cache misses. > > I'm still not getting it, how do we end up trying to allocate memory > from under raw spinlocks if you're not allowed to use kfree_rcu() under > one ? You are indeed not allowed to use kfree() under a raw spinlock, given that it can acquire a non-raw spinlock. But kfree_rcu() was just a wrapper around call_rcu(), which can be and is called from raw atomic context. > Can someone please spell out the actual problem? And as noted above, reducing the kfree()-time cache misses would be a good thing. Thanx, Paul
