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 RCU branching for the v4.19 merge window 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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.