linux-kernel - Re: [PATCH v1 1/1] lib/crypto: tests: Add KUnit tests for AES

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260116223015.60887d5d@pumpkin>
Date: Fri, 16 Jan 2026 22:30:15 +0000
From: David Laight <david.laight.linux@...il.com>
To: Holger Dengler <dengler@...ux.ibm.com>
Cc: Eric Biggers <ebiggers@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
 "Jason A . Donenfeld" <Jason@...c4.com>, Herbert Xu
 <herbert@...dor.apana.org.au>, Harald Freudenberger <freude@...ux.ibm.com>,
 linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v1 1/1] lib/crypto: tests: Add KUnit tests for AES

On Fri, 16 Jan 2026 21:55:04 +0100
Holger Dengler <dengler@...ux.ibm.com> wrote:

> On 16/01/2026 20:44, Eric Biggers wrote:
...
> > The warm-up loops in the existing benchmarks are both for cache warming
> > and to get the CPU frequency fast and fixed.  It's not anything
> > sophisticated, but rather just something that's simple and seems to
> > works well enough across CPUs without depending on any special APIs.  If
> > your CPU doesn't do much frequency scaling, you may not notice a
> > difference, but other CPUs may need it.  
> 
> Do you have a gut feeling how many iterations it takes to get the CPU speed
> up? If it takes less than 50 iterations, it would be sufficient with the new
> method.

It may not matter what you do to get the cpu speed fixed.
Looping calling ktime_get_ns() for 'long enough' should do it.
That would be test independent but the 'long enough' very
cpu dependent.
The benchmarks probably ought to have some common API - even if it
just in the kunit code.

The advantage of counting cpu clocks is the frequency then doesn't
matter as much - L1 cache miss timings might change.

The difficulty is finding a cpu clock counter. Architecture dependent
and may not exist (you don't want the fixed frequency 'sanitised' TSC).

	David