All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH V3] lib: multiply the max_runtime if detect slow kconfigs
Date: Mon, 16 Dec 2024 13:28:48 +0100	[thread overview]
Message-ID: <20241216122848.GA587325@pevik> (raw)
In-Reply-To: <CAEemH2dRjvTkvmJ1tXGq9FXbKZETjhAbe90s4-ayCzygc5jonQ@mail.gmail.com>

Hi Li,

...
> > > +/*
> > > + * List of kernel config options that may degrade performance when
> > enabled.
> > > + */
> > > +static struct tst_kconfig_var slow_kconfigs[] = {
> > > +     TST_KCONFIG_INIT("CONFIG_PROVE_LOCKING"),
> > > +     TST_KCONFIG_INIT("CONFIG_LOCKDEP"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_SPINLOCK"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_RT_MUTEXES"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_MUTEXES"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_PAGEALLOC"),
> > Does CONFIG_DEBUG_PAGEALLOC itself prolong the run? Isn't it that only when
> > debug_guardpage_minorder=... or debug_pagealloc=... is set?

> Good catch.

> I guess that won't impact the kernel performance if not set any
> of the parameters, because from the doc it is disabled by default.

>   "When CONFIG_DEBUG_PAGEALLOC is set, this parameter
>   enables the feature at boot time. In default, it is disabled.
>   ....
>   if we don't enable it at boot time and the the system will work
>   mostly same with the kernel built without CONFIG_DEBUG_PAGEALLOC."

> So I would like to remove CONFIG_DEBUG_PAGEALLOC from
> the detecting.

Or maybe to detect if debug_pagealloc kernel cmdline is set with tst_kcmdline_parse()?

OTOH we run with debug_pagealloc=on only syscalls and some long running tests
(e.g. bind06) are even slightly faster than when running without it. But that
may be affected by QEMU host. Therefore let's skip CONFIG_DEBUG_PAGEALLOC until
I find a time to test how it affects the runtime.

> > https://www.kernel.org/doc/html/v5.2/admin-guide/kernel-parameters.html

> > I would need to run the test with these to see the difference.


> Any new found?

I'm sorry I haven't tested yet. Feel free to not to wait and merge. I'll try to
do it soon.

Kind regards,
Petr


> > > +     TST_KCONFIG_INIT("CONFIG_KASAN"),
> > > +     TST_KCONFIG_INIT("CONFIG_SLUB_RCU_DEBUG"),
> > > +     TST_KCONFIG_INIT("CONFIG_TRACE_IRQFLAGS"),
> > > +     TST_KCONFIG_INIT("CONFIG_LATENCYTOP"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_NET"),
> > > +     TST_KCONFIG_INIT("CONFIG_EXT4_DEBUG"),
> > > +     TST_KCONFIG_INIT("CONFIG_QUOTA_DEBUG"),
> > > +     TST_KCONFIG_INIT("CONFIG_FAULT_INJECTION"),
> > > +     TST_KCONFIG_INIT("CONFIG_DEBUG_OBJECTS")
> > > +};
> > > +
> > > +int tst_has_slow_kconfig(void)
> > > +{
> > > +     unsigned int i;
> > > +
> > > +     tst_kconfig_read(slow_kconfigs, ARRAY_SIZE(slow_kconfigs));
> > > +
> > Maybe here TINFO message "checking for options which slow the execution?
> > Or print it (once) only if option detected? Because it's not obvious why
> > we are
> > detecting it. Or after searching print what we did (4x prolonged runtime).


> Agree, the rest comments all look good.

+1

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2024-12-16 12:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12  6:04 [LTP] [PATCH V3] lib: multiply the max_runtime if detect slow kconfigs Li Wang
2024-12-13 22:40 ` Petr Vorel
2024-12-16  9:37   ` Li Wang
2024-12-16 12:28     ` Petr Vorel [this message]
2024-12-17  2:40       ` Li Wang
2024-12-16 13:00   ` Cyril Hrubis
2024-12-16 17:29     ` Petr Vorel
2024-12-17  3:46     ` Li Wang
2024-12-18  3:23       ` Li Wang
2024-12-16 12:51 ` Cyril Hrubis
2024-12-19 12:53 ` Petr Vorel
2024-12-19 13:07   ` Li Wang
2024-12-19 12:57 ` Martin Doucha
2024-12-19 13:07   ` Petr Vorel
2024-12-19 13:12     ` Li Wang
2024-12-19 13:28       ` Petr Vorel
2024-12-19 13:29         ` Cyril Hrubis
2024-12-20  3:59           ` Li Wang
2024-12-20  7:19             ` Li Wang
2024-12-19 13:10   ` Cyril Hrubis
2024-12-19 13:14     ` Li Wang
2024-12-19 13:19       ` Cyril Hrubis
2024-12-19 13:22         ` Li Wang
2024-12-19 13:25           ` Petr Vorel

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=20241216122848.GA587325@pevik \
    --to=pvorel@suse.cz \
    --cc=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    /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.