Re: [RFC GIT PULL, v2] RCU changes for v4.12

From: Paul E. McKenney
Date: Wed May 10 2017 - 15:54:56 EST


On Wed, May 10, 2017 at 10:27:24AM -0700, Linus Torvalds wrote:

[ . . . ]

> parts, namely how the RCU changes apparently mess with the DRM
> selftest changes.

I am testing a merge with current linus/master, and I looked through
the commits in -next selected by:

gitk v4.11.. --no-merges --all-match --grep=drm --grep=selftest

I didn't find anything obvious. If the tests complete successfully,
I will try running the DRM selftest.

[ . . . ]

> And for Paul: the RCU subsystem is starting to get ridiculous. Seriously.
>
> That is *particularly* true for srcu. We don't even have all that many
> users, and I suspect a large subset of those users are just crap to
> begin with. The biggest reason for srcu seems to be bad callbacks,
> particularly shit like the mmu notifier code. Things that we probably
> shouldn't have done in the first place, and where srcu just encouraged
> people to do bad things.
>
> Seriously, do this:
>
> git grep srcu.*lock -- :^Documentation/ :^kernel/rcu/
>
> and notice that we have only a few hundred lines in the kernel that do
> srcu locking. kvm seems to be the main big user.
>
> This annoys me, because the main reason people use srcu is bad design
> and lazyness, where they can't be arsed to try to minimize locking and
> sleeping things. The "sleeping callbacks" in particular tend to be a
> huge design mistake.
>
> Yet, despite this fairly limited use, rscu seems to be just growing
> and bloating, and making more and more excuses fro bad behavior.

I can certainly revisit the uses. If it ends up that no SRCU users
really need SRCU, then it should of course be removed.

> And it was *years* since I asked you to look at getting rid of the
> absolutely insane proliferations of different RCU models. I don't
> think anything ever happened. We *still* have TREE_RCU,| PREEMPT_RCU,
> and TINY_SRCU.

I did remove TINY_PREEMPT_RCU in response to your request.

I have also removed the Kconfig parameters SRCU_SYNCHRONIZE_DELAY,
RCU_CPU_STALL_DETECTOR, PROVE_RCU_DELAY, RCU_CPU_STALL_VERBOSE,
CONFIG_RCU_FANOUT_EXACT, CONFIG_RCU_CPU_STALL_INFO, and
RCU_TORTURE_TEST_RUNNABLE. There are quite a few more that could
be removed:

o RCU_TORTURE_TEST_SLOW_PREINIT, RCU_TORTURE_TEST_SLOW_PREINIT_DELAY,
RCU_TORTURE_TEST_SLOW_PREINIT_DELAY, RCU_TORTURE_TEST_SLOW_INIT,
RCU_TORTURE_TEST_SLOW_INIT_DELAY, RCU_TORTURE_TEST_SLOW_CLEANUP,
and RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY. I will queue patches
to remove these.

o I believe that RCU_CPU_STALL_TIMEOUT could be dropped in favor
of the existing rcupdate.rcu_cpu_stall_timeout kernel parameter,
I will queue a patch and see if anyone screams.

o RCU_KTHREAD_PRIO could be dropped in favor of the existing
rcutree.kthread_prio kernel parameter. I will queue a patch,
and I would be very surprised if anyone screamed.

o RCU_BOOST_DELAY could be a boot parameter. I will queue a
patch.

o I believe that PROVE_RCU_REPEATEDLY could be a boot parameter,
I will queue a patch and see if anyone screams.

o Not sure about SPARSE_RCU_POINTER, will try making this
unconditional and see if anyone screams.

o It might be possible to eliminate RCU_NOCB_CPU_NONE,
RCU_NOCB_CPU_ZERO, and RCU_NOCB_CPU_ALL. I will look
into this.

> And with this pull request we now have CLASSIC_SRCU, TINY_SRCU,
> TREE_SRCU and TASKS_RCU.

I have a calendar reminder to remove CLASSIC_SRCU near the end of this
year. Given the testing results thus far, I would be happy to remove
it sooner if you would prefer.

> That's in addition to all the other insane tweaks that nobody uses (eg
> RCU_FANOUT etc) and that I made sure got removed from any sane
> questionnaire.

I use RCU_FANOUT and RCU_FANOUT_LEAF to test code paths on small systems
that would otherwise only be exercised on systems with thousands of CPUs.
I am not aware of any other use. If it would help, I would be happy to
move them to lib/Kconfig.debug and make them depend on TORTURE_TEST.

> Paul, this really needs to stop.
>
> I'm now going to stop pulling any more crazy RCU crap. Seriously. If
> the RCU subsystem doesn't start shrinking, I'm no longer pulling. Send
> me fixes, but don't send me more of this crazy stuff.
>
> So this is me putting my foot down. I should have done it long ago.
> I'm done with crazy. Don't waste your time doing yet another RCU mode,
> because I will not take it. And don't waste your time expanding on the
> existing ones without looking at which of those things can be removed.

OK, nothing more from RCU other than fixes, code reduction, and
documentation for the time being.

Thanx, Paul