lkml.org 
[lkml]   [2020]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] RCU changes for v5.10
On Mon, Oct 12, 2020 at 2:44 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> So that RCU can tell, even in CONFIG_PREEMPT_NONE=y kernels, whether it
> is safe to invoke the memory allocator.

So in what situation is RCU called from random contexts that it can't even tell?

> But either way, please let me know how you would like us to proceed.

Well, AT A MINIMUM, the pull request should damn well have made it
1000% clear that this removes a case that has existed for decades, and
that potentially makes a difference for small kernels in particular.

In fact, my personal config option - still to this day - is
CONFIG_PREEMPT_VOLUNTARY and on the kernel I'm running,
CONFIG_PREEMPT_COUNT isn't actually set.

Because honestly, the code generation of some core code looks better
that way (in places where I've historically looked at things), and the
latency arguments against it simply aren't relevant when you have 8
cores or more.

So i don't think that "make preempt count unconditional" is some small
meaningless detail.

What is so magical about RCU allocating memory? I assume it's some
debug case? Why does that debug case then have a

select PREEMPT_COUNT

like is done for PROVE_LOCKING?

> I based my
> optimism in part on your not having complained about either the patch
> series or the pull request, both of which I CCed you on:

I had already raised my concerns when that patch series was posted by
Thomas originally. I did not feel like I needed to re-raise them just
because the series got reposted by somebody else.

Linus

\
 
 \ /
  Last update: 2020-10-13 00:00    [W:0.139 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site