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