Linux 6.10 Makes AES-XTS Disk/File Encryption Much Faster For Modern Intel/AMD CPUs

[ebiggers]

The choice of CPU naming was from my patches, so you could blame me for it. Really the mess is from Intel, of course. As has been pointed out, the "code names" are very commonly used, not just within Intel. They are also often used to group together different client and server processors that are architecturally very similar and can be expected to have the same cycles-per-byte performance. For example I did the "Ice Lake" benchmark on an Ice Lake server processor, which is also known as "3rd generation Xeon Scalable", but the result should also apply to Ice Lake client which is "10th generation Core".

[jacob]

At what cost?
Again the performance increase by taking shortcuts that will be discovered and mitigated in the years to come?

AFAIK its by using AVX-512.

[[deXter]]

Silly question, to take advantage of this (in addition to having a modern CPU), you'd need to compile the kernel with MARCH = native or x86-64-v4 right? So if you're just using the default kernel provided by a mainstream distro, you'd never see the benefits of this?

[Anux]

This is awesome, but for my system at least my

cryptsetup benchmark

result for aes-xts still exceeds my read and write speeds.

And if it becomes faster all the better, less energy consumption and more free resources for other stuff.

[ebiggers]

Silly question, to take advantage of this (in addition to having a modern CPU), you'd need to compile the kernel with MARCH = native or x86-64-v4 right? So if you're just using the default kernel provided by a mainstream distro, you'd never see the benefits of this?

No, there's no special compiler flag needed. The code is always built (as long as CONFIG_CRYPTO_AES_NI_INTEL is enabled, which it almost always is), and like the rest of the kernel's crypto code, a runtime check of the cpuid is used to ensure that it is only executed on CPUs that support it.