Received-SPF: pass (google.com: domain of linux-kernel+bounces-47806-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <a2396ae072d6f9e009b5de558efe166b844a1397.1706718625.git.geert+renesas@glider.be>
 <ZbqFsroYDjSoYEps@1wt.eu>
In-Reply-To: <ZbqFsroYDjSoYEps@1wt.eu>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu, 1 Feb 2024 09:49:33 +0100
Message-ID: <CAMuHMdWrjag3icVi2mJbtEftwz_jH51Ov4-FAV67Mdz7UvxQXw@mail.gmail.com>
Subject: Re: [PATCH/RFC] lib: add CPU MHz benchmark test
To: Willy Tarreau <w@1wt.eu>
Cc: linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Willy,

On Wed, Jan 31, 2024 at 6:39=E2=80=AFPM Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Jan 31, 2024 at 05:46:48PM +0100, Geert Uytterhoeven wrote:
> > When working on SoC bring-up, (a full) userspace may not be available,
> > making it hard to benchmark the CPU performance of the system under
> > development.  Still, one may want to have a rough idea of the (relative=
)
> > performance of one or more CPU cores, especially when working on e.g.
> > the clock driver that controls the CPU core clock(s).
> >
> > Hence add the CPU MHz benchmark test[1], which estimates the clock
> > frequency of the CPU core it is running on, and make it available as a
> > Linux kernel test module.
> >
> > When built-in, this benchmark can be run without any userspace present.
>
> That's a great idea, I never thought about turning it into a module!
>
> > Parallel runs (run on multiple CPU cores) are supported, just kick the
> > "run" file multiple times.
>
> Hmmm does it mean it will run on the CPU that writes this "run" ?
> Because this could allow one to start tests using e.g.:
>
>     taskset -c $CPU tee /sys/.../run <<< y

That does indeed work.

> But we could also wonder if it wouldn't be easier to either send "y"
> to /sys/.../cpu0/run or may just send the CPU number to "run" instead
> of "y".

That would complicate the code a lot.

> In my experience with this tool, you most always want to easily
> control the CPU number because SoCs these days are not symmetrical at
> all.

That's why it prints the CPU number ;-)

On multi-core systems, you can also do e.g.

    for i in $(seq $(nproc)); do echo yes >
/sys/module/test_mhz/parameters/run & done

and collect the results for all CPU cores.

BTW, this is the same for test_dhry.

> Another point is that it would be nice if there was a way to present
> the result in a form that a script can retrieve from the directory,
> maybe the last measurement or something like this. I know that scripts
> are commonly used to check for a machine's correct behavior, and I try
> to encourage users to verify that it's working well, so anything we can
> do that makes it easier to use would be welcome.

I'll give that a try...

> But overall, I like it! You've got my ack.

Thanks!

> Hmmm I don't know if this is intended, the SPDX tag says MIT but the
> MODULE_LICENSE at the top says MIT/GPL. I can't say I care that much but
> I preferred to report it in case it's an accident ;-)

That must be an oversight.  I'll change the SPDX-License-Identifier to
"GPL-2.0 OR MIT".

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds