From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754766AbdEJTyq (ORCPT ); Wed, 10 May 2017 15:54:46 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54234 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753479AbdEJTyn (ORCPT ); Wed, 10 May 2017 15:54:43 -0400 Date: Wed, 10 May 2017 12:54:40 -0700 From: "Paul E. McKenney" To: Linus Torvalds Cc: Ingo Molnar , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner Subject: Re: [RFC GIT PULL, v2] RCU changes for v4.12 Reply-To: paulmck@linux.vnet.ibm.com References: <20170501095915.rm4zi5z4ta44il5p@gmail.com> <20170509072640.sbvhtjy7mcw7ndo3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17051019-0008-0000-0000-00000218980E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007044; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000210; SDB=6.00858801; UDB=6.00425567; IPR=6.00638275; BA=6.00005342; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015401; XFM=3.00000015; UTC=2017-05-10 19:54:41 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051019-0009-0000-0000-00003539613D Message-Id: <20170510195440.GW3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-10_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100136 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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