From: Matthieu Baerts <matttbe@kernel•org>
To: Jakub Kicinski <kuba@kernel•org>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"netdev-driver-reviewers@vger•kernel.org"
<netdev-driver-reviewers@vger•kernel.org>
Subject: Re: [TEST] Wiki / instructions
Date: Wed, 7 Feb 2024 09:50:48 +0100 [thread overview]
Message-ID: <bd1462f0-83e9-4c0d-8591-e76eb002fb08@kernel.org> (raw)
In-Reply-To: <20240206173705.544f4cb2@kernel.org>
Hi Jakub,
Thank you for your reply!
On 07/02/2024 02:37, Jakub Kicinski wrote:
> On Mon, 5 Feb 2024 18:21:56 +0100 Matthieu Baerts wrote:
>> Thank you for this wiki page, and all the work with the CI infrastructure!
>>
>> For the debug options, I see that you are using:
>>
>> kernel/configs/x86_debug.config
>>
>> It looks like this is specific for the 'tip' tree:
>>
>> Debugging options for tip tree testing
>>
>> I don't know if it is still maintained, e.g. it includes DEBUG_SLAB
>> option. But also, it enables options that are maybe not needed: GCOV?
>> X86_DEBUG_FPU?
>> Maybe it is better not to use this .config file, no?
>
> I haven't looked to closely. I noticed that the basic debug config
> doesn't enable LOCKDEP ?! so I put the x86 one on top.
I was surprised not to see LOCKDEP there, but in fact, it is: it enables
PROVE_LOCKING, which selects LOCKDEP and a few other DEBUG_xxx ones.
So maybe it is not needed to include the x86 one?
> I added a local patch to cut out all the obviously pointless stuff from
> x86_debug.config
Thank you!
> we should probably start our own config for networking
> at some stage.
Good idea!
On our side, we always enable DEBUG_NET, and the "debug" environment
also has NET_NS_REFCNT_TRACKER. We should probably enable
NET_DEV_REFCNT_TRACKER too.
Do you want me to add a new file in "kernel/configs" for net including
these 3 options?
Not directly related to "Net", we also enable DEBUG_INFO (+ compressed)
everywhere + KFENCE in the "non-debug" env only, disable RETPOLINE (+
mitigations=off) not to slow down the tests in already slow envs, and
disable a few components we don't need to accelerate the build and boot:
DRM, SOUND, etc.
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker/blob/latest/entrypoint.sh#L284
It is also possible to add some kconfig in the selftests if preferred,
e.g. in
./tools/testing/selftests/net/debug.config
>> For our CI validating MPTCP tests in a "debug" mode, we use
>> "debug.config" without "x86_debug.config". On top of that, we also
>> disable "SLUB_DEBUG_ON", because the impact on the perf is too
>> important, especially with slow environments. We think it is not worth
>> it for our case. You don't have the same hardware, but if you have perf
>> issues, don't hesitate to do the same ;)
>
> The mptcp tests take <60min to run with debug enabled, and just
> a single thread / VM. I think that's fine for now. But thanks for
> the heads up that SLUB_DEBUG_ON is problematic, for it may matter for
> forwarding or net tests.
The longest MPTCP selftest is currently stopped after 30 minutes due to
the selftest timeout. I will see what we can do. That's not just because
of SLUB_DEBUG_ON, that's normal to be very slow in such particular env.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2024-02-07 8:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 17:31 [TEST] Wiki / instructions Jakub Kicinski
2024-02-05 17:21 ` Matthieu Baerts
2024-02-07 1:37 ` Jakub Kicinski
2024-02-07 8:50 ` Matthieu Baerts [this message]
2024-02-07 15:21 ` Jakub Kicinski
2024-02-07 15:59 ` Matthieu Baerts
2024-02-08 2:11 ` Jakub Kicinski
2024-02-09 10:25 ` Simon Horman
2024-02-09 15:30 ` Jakub Kicinski
2024-02-16 17:01 ` Simon Horman
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=bd1462f0-83e9-4c0d-8591-e76eb002fb08@kernel.org \
--to=matttbe@kernel$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=netdev-driver-reviewers@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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