linux-kernel - Re: [PATCH/RFC] lib: add CPU MHz benchmark test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWrjag3icVi2mJbtEftwz_jH51Ov4-FAV67Mdz7UvxQXw@mail.gmail.com>
Date: Thu, 1 Feb 2024 09:49:33 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Willy Tarreau <w@....eu>
Cc: linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC] lib: add CPU MHz benchmark test

Hi Willy,

On Wed, Jan 31, 2024 at 6:39 PM Willy Tarreau <w@....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

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg

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