Linux kernel 6.12 by no means 3888.9 percent faster according to developers

The developer of a change that is supposed to make the Linux kernel 3888.9 percent faster, according to numerous news reports and Internet videos, has had enough of the hype and has made it clear: There is no major performance advantage in practice, because this gigantic increase is only due to a negligible and impractical peculiarity of the measurement method used. At the same time, Vlastimil Babka pointed out that something else was hardly noticed: The test report mentioning the increase also mentions a slowdown of just under 9 percent in a second benchmark.

The whole story is even more complicated, because the hyped change made for Linux 6.12 does bring a speed gain on some systems. Memory management developer and SLUB maintainer Vlastimil Babka introduced this – ultimately only one-line – adjustment after a user complained that the Darktable benchmark had been achieving 15 to 25 percent worse values for RAW-to-JPG conversion for several months.

Just like a second, similar bug report about speed losses of up to 600 percent, the problem was found with all kinds of AMD processors, but not with Intel processors.

Crux of the matter: memory page size and alignment

A change integrated in Linux 6.7 was quickly identified as the culprit; at the time, this was attested to have a 95.3 percent performance loss with the benchmark used, but the developers classified this as irrelevant. This adjustment allows the kernel to start requested memory areas under certain conditions in places that enable modern processors to automatically use large memory pages (Transparent Huge Pages/THP). However, as Babka noted, in some cases CPUs have to allocate around 2 megabytes of additional memory and thus also clean up –, which makes some processors significantly more work than others due to implementation details or various optimization strategies, resulting in the losses.

As a result of the change made for 6.12, the kernel now dispenses with such an alignment in a further case. Those interested in the details can find them in Babkas' mail, in which he classifies the performance gain as insignificant. There he also explains why the benchmark first dropped by over 95 percent and is now up by almost 4000: It repeatedly creates 128 MByte buffers, but in practice never uses them, instead only accessing the header once; as a result, the overhead of the changes made in 6.7 had a massive impact, which the change made for 6.12 corrects.

In the meantime, the change has already been integrated into Linux 6.11.7 released on November 8th – and has thus been reaching users of distributions such as Arch Linux, Fedora Linux or openSUSE Tumbleweed via updates for several days. Only users who own one of the problematic processors and at the same time use software such as Darktable, where the memory alignment introduced in 6.7 led to a significant loss of performance, are likely to notice a gain in speed.

The change may also lead to losses for some users, as the second measurement result of the hyped performance analysis shows, which often attests to a loss of 9.2 percent in another benchmark. However, no one has yet investigated this. However, this is not surprising, as these measurements find such gains or losses every now and then.

In many cases, such fluctuations in the results are more of a theoretical nature and have no or negligible significance in practice. Developers therefore sometimes pay no attention to them. In their circles, they also often mock providers, mostly financed by advertising, who regularly produce reports or videos on supposedly large gains with their own benchmarks or those carried out by others, but at the same time ignore many significant changes. In this case, however, Babka apparently felt compelled to put the gains in perspective.

(nie)