LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RCU branching for the v4.19 merge window
Date: Tue, 22 May 2018 09:05:34 -0700 [thread overview]
Message-ID: <20180522160534.GT3803@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180522112736.4b44ae3c@gandalf.local.home>
On Tue, May 22, 2018 at 11:27:36AM -0400, Steven Rostedt wrote:
> On Thu, 17 May 2018 07:40:44 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > Hello, Steve!
> >
> > Another year, another difficult-to-branch set of RCU commits.
> >
> > In happy contrast to last year, I can make some branches (SRCU, some
> > of the torture commits, and a few miscellaneous commits), but I will
> > likely end up with several short branches and one huge one. My thought
> > is to keep the long branch, but email the patches out in a few separate
> > serieses, with each depending on its predecessor. For example, one series
> > from the big branch would be folding the ->gpnum and ->completed fields
> > into a single ->gp_seq, which helps the RCU-flavor consolidation task.
> > Another series suppresses some rare false-positive splats that have been
> > plaguing me for more than a year. Yet another series within this huge
> > branch applies and optimizes funnel locking for grace-period startup.
> >
> > The problem is that the conversion to ->gp_seq has a very large footprint,
> > which of course generates lots of conflicts. I could of course collapse
> > these commits into a single commit, but if I did that I would also defer
> > to the merge window following v4.19 due to the resulting loss of bisection
> > within that change.
> >
> > Any advice?
> >
> > The commits are for-mingo..rcu/dev in my -rcu tree.
>
> I don't see these branches (and I don't pull tags).
You don't see them yet because I don't create them until after -rc1 time,
which is a few weeks out. If you go far enough down from rcu/dev you
will see branches (about 90 commits down from HEAD), but these branches
are already in -tip for v4.18.
> How bad are the conflicts? Or is it too late to respond to help (sorry,
> was on vacation :-)
The conflicts are already causing me substantial hassles when rebasing
bug fixes back to the buggy commits, so the conflicts are non-trivial.
Hence my reaching out to you, given your discomfort with last year's
long-chain RCU submission.
And you do have some time to respond. ;-)
Thanx, Paul
prev parent reply other threads:[~2018-05-22 16:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 14:40 Paul E. McKenney
2018-05-22 15:27 ` Steven Rostedt
2018-05-22 16:05 ` Paul E. McKenney [this message]
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=20180522160534.GT3803@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--subject='Re: RCU branching for the v4.19 merge window' \
/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
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).