From: Petr Mladek <pmladek@suse.com>
To: Luis Chamberlain <mcgrof@kernel.org>
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: Tue, 10 Jan 2023 10:57:21 +0100 [thread overview]
Message-ID: <Y702gW+5P5EepCkG@alley> (raw)
In-Reply-To: <Y7ythXxlzsJkFQcd@bombadil.infradead.org>
On Mon 2023-01-09 16:12:53, Luis Chamberlain wrote:
> 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?
How many people cares about kallsyms performance, please?
Is it worth spending time one implementing and maintaining such a
selftest?
Yes, Zhen wanted to make it faster. But how likely will anyone else
try to make it even better? Do we need to spend time on this
in the meantime?
> 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.
From my POV, it would be much more important to check if the API
works as expected. I mean that it gives the right results.
I am not sure that performance is that important to spend more time
on this one.
Also I am not sure if selftests are the right location for performance
tests. My understanding is that it is a framework for functional
testing. It is showing if the tests passed or not. But performance
tests do not give "pass or not" results.
Best Regards,
Petr
next prev parent reply other threads:[~2023-01-10 9:57 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
2023-01-10 9:57 ` Petr Mladek [this message]
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=Y702gW+5P5EepCkG@alley \
--to=pmladek@suse.com \
--cc=anders.roxell@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--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®