From: Mathieu Desnoyers <email@example.com>
To: rostedt <firstname.lastname@example.org>
Cc: Ingo Molnar <email@example.com>,
Peter Zijlstra <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
paulmck <firstname.lastname@example.org>, Stefan Metzmacher <email@example.com>,
Subject: Re: [PATCH 2/3] Fix: tracepoint: static call function vs data state mismatch (v2)
Date: Thu, 5 Aug 2021 15:42:54 -0400 (EDT) [thread overview]
Message-ID: <1847120259.7313.1628192574061.JavaMail.firstname.lastname@example.org> (raw)
----- On Aug 5, 2021, at 3:38 PM, rostedt email@example.com wrote:
> On Thu, 5 Aug 2021 15:15:43 -0400 (EDT)
> Mathieu Desnoyers <firstname.lastname@example.org> wrote:
>> ----- On Aug 5, 2021, at 2:56 PM, rostedt email@example.com wrote:
>> > Note, there shouldn't be a "(v2)" outside the "[PATCH ]" part.
>> > Otherwise it gets added into the git commit during "git am".
>> Out of curiosity, do you know any way to annotate my local commits to have the
>> [PATCH v2] tag automatically generated by git send-email ?
> I pass -v2 to git send-email, and it adds the v2 for me.
OK, so you version the entire patch series in one go. It makes sense.
>> > This is a big enough regression, I'll even add a Fixes tag to the next
>> > patch on the final sha1 of this patch! Such that this patch won't be
>> > backported without the next patch.
>> This makes sense. I still wanted to keep the two patches separate so we would
>> introduce the (slow) state machine in the first patch, and optimize for
>> speed in the second. My intent is to facilitate of small logical changes,
>> and make bisection more precise in the future if we introduce an issue
> I agree which is why I didn't ask you to fold them. The logic in this
> code was a big enough change, where I agree it should be kept separate.
> Unfortunately, it caused a huge performance regression :-(, but at the
> same time, fixed a correctness issue, which Thomas always says that
> correctness trumps performance.
> But the compromise is to add a Fixes tag to the next patch and document
> why they are separated, but still required to act as "one". I'll add
> that commentary.
> -- Steve
>> Calling out more clearly how slow things become with this patch is indeed
next prev parent reply other threads:[~2021-08-05 19:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 13:27 [PATCH 0/3] tracepoint static call fixes Mathieu Desnoyers
2021-08-05 13:27 ` [PATCH 1/3] Fix: tracepoint: static call: compare data on transition from 2->1 callees Mathieu Desnoyers
2021-08-05 17:07 ` Steven Rostedt
2021-08-05 17:57 ` Mathieu Desnoyers
2021-08-05 13:27 ` [PATCH 2/3] Fix: tracepoint: static call function vs data state mismatch (v2) Mathieu Desnoyers
2021-08-05 18:56 ` Steven Rostedt
2021-08-05 19:15 ` Mathieu Desnoyers
2021-08-05 19:38 ` Steven Rostedt
2021-08-05 19:42 ` Mathieu Desnoyers [this message]
2021-08-05 13:27 ` [PATCH 3/3] Fix: tracepoint: rcu get state and cond sync for static call updates (v2) Mathieu Desnoyers
2021-08-05 19:12 ` Steven Rostedt
2021-08-05 19:29 ` [PATCH v3 1/1] Fix: tracepoint: rcu get state and cond sync for static call updates Mathieu Desnoyers
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).