mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>,
	linux-kernel@vger.kernel.org, linux-modules@vger.kernel.org,
	Anders Roxell <anders.roxell@linaro.org>
Subject: Re: [PATCH v2] kallsyms: Fix sleeping function called from invalid context when CONFIG_KALLSYMS_SELFTEST=y
Date: Mon, 9 Jan 2023 16:12:53 -0800	[thread overview]
Message-ID: <Y7ythXxlzsJkFQcd@bombadil.infradead.org> (raw)
In-Reply-To: <Y7wZSxw+Ys5MNf8g@alley>

On Mon, Jan 09, 2023 at 02:40:27PM +0100, Petr Mladek wrote:
> Why are try hardly comparable?
> 
> 1. The speed depends on the number of loaded modules
>    and number of symbols. It highly depends on the configuration
>    that was used to build the kernel.
> 
> 2. The test runs only once. As a result it is hard to judge
>    how big is the noise.
> 
> 3. The noise might depend on the size and state of CPU caches.
> 
> 
> I personally vote for removing this selftest!

Even so, just as with testing a filesystem with different types of
configurations, at least testing a few configs helps and it's what
we do. Then, if anyone ever wanted to try to increase performance
on symbol lookup today they have no easy way to measure things. How
would they go about comparing things performance without this selftest?

This selftests helps generically with that *and* helps peg on to it any sanity
checks you may wish to add to those APIs which we just don't want to do
upstream.

That was the rationale behind it, just as with any other selftest.

However, if measuring the time is not possible that's separate topic.
But to say that measuring time on some config is not valuable I think
is not a fair statement. Yes, the noise things are good points, but
the test can be enhanced for that too. And any patch which anyone
in the future would try to propose for new enhancements would likely
be looking at obvious gains beyond any type of noise.

  Luis

  reply	other threads:[~2023-01-10  0:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-28  1:45 Zhen Lei
2023-01-06 18:25 ` Luis Chamberlain
2023-01-09  3:07   ` Leizhen (ThunderTown)
2023-01-09 13:40 ` Petr Mladek
2023-01-10  0:12   ` Luis Chamberlain [this message]
2023-01-10  9:57     ` Petr Mladek
2023-01-10 12:20       ` Leizhen (ThunderTown)
2023-01-10 17:12       ` Luis Chamberlain
2023-01-10  4:05   ` Leizhen (ThunderTown)
2023-01-10  9:46     ` Petr Mladek

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=Y7ythXxlzsJkFQcd@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=anders.roxell@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=thunder.leizhen@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®