All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Mina Almasry <almasrymina@google.com>
Cc: patchwork-bot+netdevbpf@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	hawk@kernel.org, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, horms@kernel.org, shuah@kernel.org,
	ilias.apalodimas@linaro.org, toke@toke.dk
Subject: Re: [PATCH net-next v5] page_pool: import Jesper's page_pool benchmark
Date: Thu, 26 Jun 2025 08:23:27 -0700	[thread overview]
Message-ID: <20250626082327.59888c1f@kernel.org> (raw)
In-Reply-To: <CAHS8izO9=Q3W9zvq4Qtoi_NGTo6QShV7=rGOjxz3HiAB+6rZyw@mail.gmail.com>

On Wed, 25 Jun 2025 17:22:56 -0700 Mina Almasry wrote:
> What I'm hoping to do is:
> 
> 1. Have nipa run the benchmark always (or at least on patches that
> touch pp code, if that's possible), and always succeed.
> 2. The pp reviewers can always check the contest results to manually
> see if there is a regression. That's still great because it saves us
> the time of cherry-pick series and running the tests ourselves (or
> asking submitters to do that).
> 3. If we notice that the results between runs are stable, then we can
> change the test to actually fail/warn if it detects a regression (if
> fast path is > # of instructions, fail).

That's fine. I don't think putting the data on a graphs would be much
work, and clicking old results out of old runs will be a PITA. Just a
little parsing in the runner to propagate it into JSON. And a fairly
trivial bit of charts.js to fetch the runs and render UI.

> 4. If we notice that the results have too much noise, then we can
> improve the now merged benchmark to somehow make it more consistent.
> 
> FWIW, when I run the benchmark, I get very repeatable results across
> runs, especially when measuring the fast path, but nipa's mileage may
> vary.

100% on board. But someone with Meta credentials needs to add a runner
and babysit it, I have enough CI wrangling as is.

Or we wait a couple of months until we migrate to a more public setup.

  reply	other threads:[~2025-06-26 15:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 18:15 [PATCH net-next v5] page_pool: import Jesper's page_pool benchmark Mina Almasry
2025-06-20  7:49 ` Toke Høiland-Jørgensen
2025-06-24  1:20 ` patchwork-bot+netdevbpf
2025-06-25 23:45   ` Mina Almasry
2025-06-26  0:03     ` Jakub Kicinski
2025-06-26  0:22       ` Mina Almasry
2025-06-26 15:23         ` Jakub Kicinski [this message]
2025-06-26 16:30           ` Mina Almasry

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=20250626082327.59888c1f@kernel.org \
    --to=kuba@kernel.org \
    --cc=almasrymina@google.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=patchwork-bot+netdevbpf@kernel.org \
    --cc=shuah@kernel.org \
    --cc=toke@toke.dk \
    /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.