Messages in this thread | | | Date | Thu, 13 Aug 2020 16:23:11 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag |
| |
On Fri, Aug 14, 2020 at 12:06:19AM +0200, peterz@infradead.org 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@infradead.org 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
| |