linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC GIT PULL, v2] RCU changes for v4.12
Date: Wed, 10 May 2017 10:27:24 -0700	[thread overview]
Message-ID: <CA+55aFyCqkbsHF6rZ79nHpCjJmNVT3ONqB0vyQTiB-GYQmts7Q@mail.gmail.com> (raw)
In-Reply-To: <20170509072640.sbvhtjy7mcw7ndo3@gmail.com>

On Tue, May 9, 2017 at 12:26 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> The main changes are:

So I've pulled it now (although it is showing signs of semantic
conflicts, so I'll have to look at those), but I've got two requests,
one for Ingo, one for Paul.

Ingo: please don't bother sending me stupid crap.

And by that I mean the whole patch WHEN IT IS 300kB IN SIZE!

That's just idiotic. Nobody is ever going to review a 300kB patch that
is ~7500 lines. All it does is waste time, and make it a pain to even
reply to your emails (since I have "include quoted original" on by
default in order to be able to quote and reply sanely).

There's a reason "git request-pull" only does the diffstat and the shortlog.

So please fix your scripts. If a patch is so big that is is not worth
reviewing, don't include it. I don't know exactly where that limit is,
but I would suggest that it is on the order of 1000 lines or so.

This is particularly annoying, because your pull request is one huge
pile of shit. It has all that completely useless stuff that nobody is
ever going to look at, and it didn't actually mention the *important*
parts, namely how the RCU changes apparently mess with the DRM
selftest changes.

So stop sending me stupid crap, and please send me the *relevant* stuff instead.

>   - Debloat RCU headers
>
>   - Parallelize SRCU callback handling (plus overlapping patches)
>
>   - Improve the performance of Tree SRCU on a CPU-hotplug stress test

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.

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.

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

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.

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.

                    Linus

  reply	other threads:[~2017-05-10 17:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01  9:59 [GIT PULL] RCU changes for v4.12 Ingo Molnar
2017-05-02  1:19 ` Linus Torvalds
2017-05-02  4:02   ` Paul E. McKenney
2017-05-02  4:11     ` Linus Torvalds
2017-05-02  4:30       ` Paul E. McKenney
2017-05-02  7:59     ` Ingo Molnar
2017-05-02  8:31       ` [PATCH] srcu: Debloat the <linux/rcu_segcblist.h> header Ingo Molnar
2017-05-02 10:25         ` Paul E. McKenney
2017-05-02 12:56           ` Paul E. McKenney
2017-05-09  7:26 ` [RFC GIT PULL, v2] RCU changes for v4.12 Ingo Molnar
2017-05-10 17:27   ` Linus Torvalds [this message]
2017-05-10 19:54     ` Ingo Molnar
2017-05-10 20:01       ` Linus Torvalds
2017-05-11  6:54         ` Ingo Molnar
2017-05-10 19:54     ` Paul E. McKenney
2017-05-10 20:17       ` Linus Torvalds
2017-05-10 20:51         ` Paul E. McKenney
2017-05-10 21:08           ` Linus Torvalds
2017-05-10 22:53             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+55aFyCqkbsHF6rZ79nHpCjJmNVT3ONqB0vyQTiB-GYQmts7Q@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).