On Mon, May 04, 2020 at 04:21:53PM +0200, Uladzislau Rezki wrote: > > > > > > > > If we are not doing single-pointer allocation, then that would also eliminate > > > > entering the low-level page allocator for single-pointer allocations. > > > > > > > > Or did you mean entry into the allocator for the full-page allocations > > > > related to the pointer array for PREEMPT_RT? Even if we skip entry into the > > > > allocator for those, we will still have additional caching which further > > > > reduces chances of getting a full page. In the event of such failure, we can > > > > simply queue the rcu_head. > > > > > > > > Thoughts? > > > > > > I was just trying to guess why you kept the single-pointer allocation. > > > It looks like I guessed wrong. ;-) > > > > > > If, as you say above, you make it go straight to synchronize_rcu() > > > upon full-page allocation failure, that would be good! > > > > Paul, sounds good. Vlad, are you also Ok with that? > > > OK, let's drop it and keep it simple :) > > BTW, for PREEMPT_RT we still can do a page allocation for single > argument of kvfree_rcu(). In case of double we just revert everything > to the rcu_head if no cache. > > For single argument we can drop the lock before the entry to the page > allocator. Because it follows might_sleep() anotation we avoid of having > a situation when spinlock(rt mutex) is taken from any atomic context. > > Since the lock is dropped the current context can be interrupted by > an IRQ which in its turn can also call kvfree_rcu() on current CPU. > In that case it must be double argument(single is not allowed) kvfree_rcu() > call. For PREEMPT_RT if no cache everything is reverted to rcu_head usage, > i.e. the entry to page allocator is bypassed. > > It can be addressed as a separate patch and send out later on if we > are on the same page. > > Paul, Joel what are your opinions? I strongly prefer that it be removed from the series. I do understand that this is a bit more hassle right now, but this does help avoid confusion in the future, plus perhaps also avoiding issues with future bisections. Thanx, Paul
