From: Jakub Kicinski <kuba@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, linux-kselftest@vger.kernel.org,
Willem de Bruijn <willemb@google.com>,
Matthieu Baerts <matttbe@kernel.org>
Subject: Re: [PATCH net-next] selftests/net: ignore timing errors in so_txtime if KSFT_MACHINE_SLOW
Date: Fri, 2 Feb 2024 15:39:09 -0800 [thread overview]
Message-ID: <20240202153909.79c08063@kernel.org> (raw)
In-Reply-To: <20240201162130.2278240-1-willemdebruijn.kernel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Thu, 1 Feb 2024 11:21:19 -0500 Willem de Bruijn wrote:
> This test is time sensitive. It may fail on virtual machines and for
> debug builds.
>
> Continue to run in these environments to get code coverage. But
> optionally suppress failure for timing errors (only). This is
> controlled with environment variable KSFT_MACHINE_SLOW.
>
> The test continues to return 0 (KSFT_PASS), rather than KSFT_XFAIL
> as previously discussed. Because making so_txtime.c return that and
> then making so_txtime.sh capture runs that pass that vs KSFT_FAIL
> and pass it on added a bunch of (fragile bash) boilerplate, while the
> result is interpreted the same as KSFT_PASS anyway.
FWIW another idea that came up when talking to Matthieu -
isolate the VMs which run time-sensitive tests to dedicated
CPUs. Right now we kick off around 70 4 CPU VMs and let them
battle for 72 cores. The machines don't look overloaded but
there can be some latency spikes (CPU use diagram attached).
So the idea would be to have a handful of special VMs running
on dedicated CPUs without any CPU time competition. That could help
with latency spikes. But we'd probably need to annotate the tests
which need some special treatment.
Probably too much work both to annotate tests and set up env,
but I thought I'd bring it up here in case you had an opinion.
[-- Attachment #2: cpu.png --]
[-- Type: image/png, Size: 75554 bytes --]
next prev parent reply other threads:[~2024-02-02 23:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 16:21 [PATCH net-next] selftests/net: ignore timing errors in so_txtime if KSFT_MACHINE_SLOW Willem de Bruijn
2024-02-02 23:39 ` Jakub Kicinski [this message]
2024-02-03 0:31 ` Willem de Bruijn
2024-02-06 9:18 ` Paolo Abeni
2024-02-06 10:38 ` Matthieu Baerts
2024-02-06 9:30 ` patchwork-bot+netdevbpf
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=20240202153909.79c08063@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=matttbe@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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 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.