On Fri, Aug 14, 2020 at 12:06:19AM +0200, pet...@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, pet...@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
