Faster checksum benchmark on system boot

[lzsaver]

System information

Type	Version/Name
Distribution Name	Gentoo
Distribution Version
Kernel Version	6.12.41
Architecture	x86_64
OpenZFS Version	2.2.8 + #17563, 2.3.4, 2.4.0_rc2

Describe the problem you're observing

During testing the patches for 2.2.9, the following behavior was observed on Gentoo after applying #17563.

implementation               1k      4k     16k     64k    256k      1m      4m     16m
edonr-generic               749     840     977    1628       0    1573    1558    1446
skein-generic               516     563     595     595       0     546     604     481
sha256-generic              101     107     111     110       0     110     111     110
sha256-x64                  255     288     178     207       0     225     298     299
sha256-ssse3                328     366     376     373       0     377     377     366
sha512-generic              290     326     337     334       0     334     310     334
sha512-x64                  400     452     462     478       0     475     465     463
blake3-generic              345     382     367     377       0     370     373     370
blake3-sse2                 424    1242    1315    1415       0    1391    1337    1356
blake3-sse41                480    1444    1636    1676       0    1608    1549    1610

The issue also occurs on the 2.3 and 2.4 branches, which already include this patch.

Describe how to reproduce the problem

cat /proc/spl/kstat/zfs/chksum_bench

Is it reproducible on your systems?

[lundman]

oo, ooh i can suggest this again!

#17563 (comment)

[behlendorf]

Sorry, but it's not clear to me. Do we end up selecting the wrong implementation here, or is it mainly a cosmetic issue?

[lzsaver]

Sorry that there are no ready answers right now, because it is unclear why zeros are being shown.
It can be assumed that @mcmilk will log in in about five hours and will clear things up.

P.S. Something ate the "Signed‑off‑by" line in the quick‑fix PR. This will be fixed.

[mcmilk]

Sorry, but it's not clear to me. Do we end up selecting the wrong implementation here, or is it mainly a cosmetic issue?

It's a cosmetic issue. I wanted to re-use the 256k benchmark value.

[mcmilk]

oo, ooh i can suggest this again!

#17563 (comment)

Yes, this makes sense.

I have two questions for implementation:

1. Should we skip all benchmarks, when the user gives us sth. like: zfs_sha512_impl=avx - or should only the sha512 tests be skipped then.
2. Should a cat /proc/spl/kstat/zfs/chksum_bench always benchmark all possible algorithms?

[lzsaver]

Should a cat /proc/spl/kstat/zfs/chksum_bench always benchmark all possible algorithms?

Yes, otherwise there is no way to display the real results obtained with the current governor.
However, we need to make sure that we always have enough memory to run the benchmark.

Update:
If something is to be skipped, how can users change their choice if they have incomplete information.
Currently, any user can make requests, which poses a risk of a DoS attack, which must be prevented.