From: Jakub Kicinski <kuba@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
MPTCP Upstream <mptcp@lists.linux.dev>,
Paolo Abeni <pabeni@redhat.com>,
Mat Martineau <martineau@kernel.org>
Subject: Re: [TEST] The no-kvm CI instances going away
Date: Tue, 6 Feb 2024 17:44:07 -0800 [thread overview]
Message-ID: <20240206174407.36ca59c4@kernel.org> (raw)
In-Reply-To: <f6437533-b0c9-422b-af00-fb8a236b1956@kernel.org>
On Tue, 6 Feb 2024 12:16:43 +0100 Matthieu Baerts wrote:
> Hi Jakub,
>
> On 06/02/2024 02:41, Jakub Kicinski wrote:
> > because cloud computing is expensive I'm shutting down the instances
> > which were running without KVM support. We're left with the KVM-enabled
> > instances only (metal) - one normal and one with debug configs enabled.
>
> Thank you for the notification!
>
> It sounds like good news if the non-support of KVM was causing issues :)
>
> I think we can then no longer ignore the two MPTCP tests that were
> unstable in the previous environment.
>
> The results from the different tests running on the -dbg instances don't
> look good. Maybe some debug kconfig have a too big impact? [1]
Sorry, I'm behind on the reading the list. FWIW if you want to reach me
quickly make sure the To: doesn't include anyone else. That gets sorted
to a higher prio folder :S
> For MPTCP, one test always hits the selftest timeout [2] when using a
> debug kconfig. I don't know what to do in this case: if we need to set a
> timeout value that is supported by debug environments, the value will be
> so high, it will no longer catch issues "early enough" in "normal"
> environments.
> Or could it be possible to ignore or double the timeout value in this
> debug environment?
>
> Also, what is the plan with this debug env? It looks like the results
> are not reported to patchwork for the moment. Maybe only "important"
> issues, like kernel warnings, could be reported? Failed tests could be
> reported as "Warning" instead of "Fail"?
Unfortunately I'm really behind on my "real job". I don't have a clear
plan. I think we should scale the timeout by 2x or so, but I haven't
looked how to do that.
I wish the selftest subsystem had some basic guidance.
next prev parent reply other threads:[~2024-02-07 1:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 1:41 [TEST] The no-kvm CI instances going away Jakub Kicinski
2024-02-06 11:16 ` Matthieu Baerts
2024-02-07 1:44 ` Jakub Kicinski [this message]
2024-02-07 9:44 ` Matthieu Baerts
2024-02-07 14:25 ` Jakub Kicinski
2024-02-07 14:37 ` Matthieu Baerts
2024-02-07 15:29 ` Jakub Kicinski
2024-02-07 16:06 ` Matthieu Baerts
2024-02-07 17:45 ` David Ahern
2024-02-07 18:55 ` Jakub Kicinski
2024-02-07 19:45 ` David Ahern
2024-02-07 20:07 ` Jakub Kicinski
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=20240206174407.36ca59c4@kernel.org \
--to=kuba@kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.