Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 2/2] bpf: fix have_attach_type() detection
Date: Mon, 17 Mar 2025 22:49:57 -0400	[thread overview]
Message-ID: <Z9jfVWtF7bekDbP8@oracle.com> (raw)
In-Reply-To: <8ec65b3f-4b6e-f6ef-fc3b-3a3117f581ab@oracle.com>

On Mon, Mar 17, 2025 at 09:36:56PM -0400, Eugene Loh wrote:
> On 3/17/25 16:20, Kris Van Hees wrote:
> 
> > On Mon, Mar 17, 2025 at 04:16:01PM -0400, Eugene Loh wrote:
> > 
> > > In what order will patches be applied?  I vote for these two ahead of the
> > > 8-patch perf series.
> > I really prefer the opposite order, mainly because the performance improvements
> > really help with speeding up the testsuite runs.
> 
> Maybe it won't matter, but the question is what one is looking for when one
> patch set is in and the other is not.  One choice is that one gets bad tests
> results... but at least they'll be faster.  The other choice is that the
> test results will still be as slow as before, but at least they'll be
> meaningful.  I vote for the latter.  (I guess the other question is what
> platform one is talking about...)  Anyhow, I vote for correctness before
> speed, but maybe we'll only test all patches at once.

There is not really an option here of having one patch set in and not the
other, so it doesn't really matter.  The perf series does not introduce any
new regressions as far as I can see, so there is no downside to applying it
first yet there is a significant benefit in terms of speeding up testing.  The
attach-type patches work around a problem with a range of kernels, which is a
problem that preceeds the perf-series already, and that fix will definitely be
in the tree right after the perf-series so the end result is good.

If easier, feel free to consider them altogether a single series rather than
two series.


      reply	other threads:[~2025-03-18  2:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 18:41 [PATCH 2/2] bpf: fix have_attach_type() detection Kris Van Hees
2025-03-17 20:16 ` Eugene Loh
2025-03-17 20:20   ` Kris Van Hees
2025-03-18  1:36     ` Eugene Loh
2025-03-18  2:49       ` Kris Van Hees [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=Z9jfVWtF7bekDbP8@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /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