The Performance Impact Of Intel's Register File Data Sampling "RFDS" Mitigation

[blackshard]

Will the kernel mitigation hurt performance on AMD CPUs?

It should not hurt any other processor which is not supposed to have such vulnerability. Also it should not hurt any other Intel processors which are not those declared in the first part of the article, since they supposedly not have this kind of vulnerability.

[filbo]

The 14900K is a hybrid processor with both P and E cores, while the vulnerability should only affect performance on E cores. Yet even your single-threaded benchmarks show small differences here (I'd expect the scheduler to quickly put and keep them on the 'best' core, which in this situation would always be a P-core).

Would it be possible to set up E-core-only benchmarks to really expose the effects? You should be able to 'park' all but one of the P-cores, then use processor affinity or some aspect of cgroups to finish the job.

This ability (to test only P or only E cores of a hybrid -- or for that matter only C or only c-cores of a modern AMD processor) is becoming a significant need, hopefully it will eventually become a routine feature of the test suite.

Please include geomean charts even in little throwaway posts like this I really prefer to see 3 geomean charts -- single-threaded tests, MT tests, and all together.

[cend]

The 14900K is a hybrid processor with both P and E cores, while the vulnerability should only affect performance on E cores. Yet even your single-threaded benchmarks show small differences here (I'd expect the scheduler to quickly put and keep them on the 'best' core, which in this situation would always be a P-core).

Would it be possible to set up E-core-only benchmarks to really expose the effects? You should be able to 'park' all but one of the P-cores, then use processor affinity or some aspect of cgroups to finish the job.

This ability (to test only P or only E cores of a hybrid -- or for that matter only C or only c-cores of a modern AMD processor) is becoming a significant need, hopefully it will eventually become a routine feature of the test suite.

Please include geomean charts even in little throwaway posts like this I really prefer to see 3 geomean charts -- single-threaded tests, MT tests, and all together.

I am not sure if Michael has an Atom Celeron testbench or anything similar. Hope they got one.

[RealNC]

CVE-2024-LOL-CPU: The "ChipperChuckle" Vulnerability

Description: The "ChipperChuckle" vulnerability affects the widest possible range of CPUs (meaning all of them,) allowing malicious actors to execute arbitrary code without proper authorization. This vulnerability stems from the fundamental ability of CPUs to execute instructions, including those intended for malicious purposes, such as malware.

Impact: Attackers can exploit this vulnerability to run code on affected systems, potentially leading to data theft, system compromise, and other malicious activities. The ability of CPUs to execute code, while essential for their functionality, poses a significant security risk when exploited by attackers.

Solution: Use a pen and some paper instead of a CPU.

[coder]

i thought that microcode mitigation can impact performance as well. so using mitigation=off might be useless with newer microcode.

No, the microcode update doesn't do anything unless/until the VERW instruction is executed by the kernel, which disabling mitigations should prevent.

[coder]

Would it be possible to set up E-core-only benchmarks to really expose the effects? You should be able to 'park' all but one of the P-cores, then use processor affinity or some aspect of cgroups to finish the job.

This.

Need to know how it affects P-cores vs E-cores.

Please include geomean charts even in little throwaway posts like this I really prefer to see 3 geomean charts -- single-threaded tests, MT tests, and all together.

Yeah, after looking at the first 3rd of the test cases, I started scrolling more quickly, in order to find the Geomean chart.

In this case, I wouldn't expect the impact to differ much, between single-threaded and multithreaded. I do find the idea of 3 Geomean charts a bit weird, since the mix of single & multi is pretty arbitrary, in any given article. I'd say: show us separate lightly-threaded and heavily-threaded geomeans, when they differ substantially. Otherwise, just having one is fine.

[Forge]

If you have an N100-based miniPC around, it's not hard to test this mitigation, since all the processor cores are E-cores. I bought one to use as a router, but had to retire/replace it due to Realtek NICs hanging all the time.

[coder]

If you have an N100-based miniPC around, it's not hard to test this mitigation, since all the processor cores are E-cores.

The ideal performance comparison would involve:

1. Test the impact on a P-core (or hybrid processor with E-cores disabled).
2. Test the impact on an E-core processor.

From what I've heard, you can't disable all P-cores on a hybrid CPU, hence the need for an E-only CPU. Without an E-only CPU, it should be almost as good if you just use affinity to restrict the benchmark to run on E-cores (i.e. via a utility like taskset), since the mitigation only affect user/kernel transitions, which should only be happening on the cores where you allow the benchmark to run.

I bought one to use as a router, but had to retire/replace it due to Realtek NICs hanging all the time.

That's a shame, not least because Intel's Ethernet controllers are buggy, too.

[Forge]

The ideal performance comparison would involve:

1. Test the impact on a P-core (or hybrid processor with E-cores disabled).
2. Test the impact on an E-core processor.

From what I've heard, you can't disable all P-cores on a hybrid CPU, hence the need for an E-only CPU. Without an E-only CPU, it should be almost as good if you just use affinity to restrict the benchmark to run on E-cores (i.e. via a utility like taskset), since the mitigation only affect user/kernel transitions, which should only be happening on the cores where you allow the benchmark to run.


That's a shame, not least because Intel's Ethernet controllers are buggy, too.

Yep. I was hoping it would work great, since the only VM still on my aged ESX host is a router (pfsense) with passed-through dual port Intel NIC. The N100 would have cut the power usage for my "router" from a few hundred watts to a dozen or so, but the Realtek NICs killed that plan. I'm currently planning for a bigger, better virtualization host in the future, and I'll be putting a dual 10Gbps NIC in, instead.

[coder]

I'm currently planning for a bigger, better virtualization host in the future, and I'll be putting a dual 10Gbps NIC in, instead.

FWIW, here's a N97 board with dual Intel 2.5 Gbps controllers:

https://mitxpc.com/products/jmtx-adn1-n97000

It's about the only one I've seen that accepts DDR5 DIMMs and its NVMe slot is x2 (unlike some that are only x1!). It's a little pricey, but it's meant to be industrial-grade. Not sure if it supports in-band ECC, but the manual doesn't say so.

Here are some Thin mini-ITX cases:

https://www.silverstonetek.com/en/product/computer-chassis/?filter=Thin_MiniITX

I like the thin aesthetic. That PT13 even has a mount for a 2.5" drive. I imagine they could make it even smaller without.