I wonder if someone has tested it for Ryzen SIGSEGVs and hangs. I know AMD said it's not affected, but it'd be good to see some third party confirmation to that.
Yes its been tested by a bunch of folks at phoronix. The script that causes issues on Ryzen has so far not caused any issues on either Epyc or ThreadRipper.
That seems like it could less destructively be done by setting CPU affinities appropriately. And, by extension, automatically through better kernel code.
> Robert Hallock on AMD's Threadripper webcast has stated that Windows Scheduler is not capable of specifically zeroing out a full die to have the same effect. The UMA/NUMA implementation can be managed with Windows Scheduler to assign threads to where the data is (or assign data to where the threads are), but as far as fully disabling a die in the OS requires a restart.
I'd put money that automatically handling the affinity per CCX would give you a good chunk of performance boost, but that it would require a substantial amount of work to the OS that wouldn't be completed before benchmarks and reviews came out.
Given that Ryzen 3/5/7 performance has improved since they were released, but only a few of the reviews have been updated, it's likely that AMD wanted to avoid that and put in Game Mode as a stopgap.
Yes, but the software actually needs to be NUMA aware. A lot of current server software works that way - groups of tightly coupled threads target the same node, which prevents major performance issues in multi-CPU systems.
In general such systems are very good at multitasking, but not so good at running a single demanding application (if it is not NUMA aware).
The same thing applies with Threadripper - albeit with lower internode latency.