Message-ID: <f5233a6a-7b89-4b5c-a136-5284440f1951@kernel.org>
Date: Wed, 7 Feb 2024 16:59:31 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "netdev-driver-reviewers@...r.kernel.org"
 <netdev-driver-reviewers@...r.kernel.org>
Subject: Re: [TEST] Wiki / instructions

On 07/02/2024 16:21, Jakub Kicinski wrote:
> On Wed, 7 Feb 2024 09:50:48 +0100 Matthieu Baerts wrote:
>> 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'm confused. Now doing:
> 
>   make O=built_test defconfig
>   make O=built_test debug.config
> 
> I don't get KASAN but I get LOCKDEP :S Bleh, maybe because of the
> options vng throws in?

Strange, I get both of them on my side.

Same if I include the two targets:

  make O=built_test defconfig debug.config

>>> 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?
> 
> Just the three? What about KASAN, OBJECT debug, DEBUG_VM etc?
> As much as we can without going over the 3h limit in the tests :)

Sorry, I meant to say: we would use the existing "debug.config" + a new
"net_debug.config" containing these 3 options (and maybe more that are
specific to the net tree).

>> Not directly related to "Net", we also enable DEBUG_INFO (+ compressed)
>> everywhere
> 
> We have debug_info, maybe vng adds it..

Great!

>> + KFENCE in the "non-debug" env only,
> 
> We could do KFENCE I guess. I'm a bit surprised it's not on by default
> for x86. My first choice would be to try to change that..

Good point. I can ask KFENCE maintainers what they think about that.

>> 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:
> 
> RETPOLINE we could kill, agreed

I still need to check vrg: is it easy to add kconfig you want to
enable/disable? Do you need a new file? Should we maintain this file in
the tree?

>> DRM, SOUND, etc.
>>
>> https://github.com/multipath-tcp/mptcp-upstream-virtme-docker/blob/latest/entrypoint.sh#L284
> 
> Yes, vng also adds some stuff we don't need in this area :(

With the non-ng virtme, I disable those:

  -d PCCARD -d MACINTOSH_DRIVERS -d SOUND -d USB_SUPPORT -d NEW_LEDS
  -d SURFACE_PLATFORMS -d DRM -d FB

I will check when I will switch to vng to see what else we can disable.
But on your side, you probably have more CPU resources to compile the
kernel, and that's fine to keep them :)

>> It is also possible to add some kconfig in the selftests if preferred,
>> e.g. in
>>
>>   ./tools/testing/selftests/net/debug.config
> 
> Would be great if everyone didn't have to go thru this exercise.
> How about we start sending patches to kernel/configs/debug.config
> and see if anyone screams at us?

I guess the 3 net debug ones could go there indeed.

Do you want me to try?

>>>> 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.
> 
> I'll 2x the timeouts before reporting debug to patchwork, so don't
> worry about it, yet. 

Thanks :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Powered by blists - more mailing lists