The rest of the 6.3 merge window [LWN.net]

The rest of the 6.3 merge window

Posted Mar 8, 2023 1:29 UTC (Wed) by edeloget (subscriber, #88392)
In reply to: The rest of the 6.3 merge window by mb
Parent article: The rest of the 6.3 merge window

> *checking my calendar*.

> Yeah, kind of nice.
> The coding style is awful, though. And not very kernel like at all.
>I would have expected it to be cleaned up before getting merged.
> The kernel is not a museum for historic code dumps.

I guess the style has been kept in order to make sure that the code was doing exactly what it says it does, including the "I need to make sure that the output can be compared to all other DMIPS outputs out there". I haven't looked the whole patch, but this may even come with special compiler options in order to make sure the compiler is not doing some nasty optimization that would lead to non-comparable results.

to post comments

The rest of the 6.3 merge window

Posted Mar 8, 2023 9:13 UTC (Wed) by geert (subscriber, #98403) [Link]

Indeed, I only changed whitespace and basic formatting to please scripts/checkpatch.pl, to avoid impact on the measurements:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/ren...
In theory, a synthetic benchmark can be optimized away entirely by a sufficiently smart compiler. That's also why the benchmark is split in two source files.

The figures cannot be compared accurately, as they depend heavily on compiler version and compiler options (some dictated by the kernel build system). They do work fine for my intended usage (verifying CPU core clock speeds), as DMIPS/MHz is reliable.

Typically, on e.g. arm32, I get 25% less DMIPS with the in-kernel version than with the userspace version (https://github.com/qris/dhrystone-deb.git).
Even with the latter, I saw differences up to 19% using gcc-4.9/6.3/7.4/8.3/9.3/10.2 (6.3 was worst, 10.2 was best).