0

I am doing a school project regarding the Meltdown patches and how it affects performance, and was doing some disk benchmarks (CrystalDiskMark).

Current setup is i5-8600K + Samsung 860Evo 250GB, and to my surprise, the Meltdown patch increased performance... in both Read and Write by very small numbers... (did 3 trials).. I tried the 4KiB Q32 T1 test.

So I reasoned that maybe it's because the CPU is too fast for the SSD and ran a CPU stress test in the background while benchmarking the disks

Even on a PCID disabled laptop, while the read speed decreased by 8%, the write speed increased by 20% (without stress test in background)

and I get 7% decrease in disk performance after the patch (36.85 --> 34.27 / 28.66 -->26.66MB/s)

Is this the correct way to benchmark the performance hit caused by the patch? And why does the patch increase performance at low CPU loads? I read the comments on this post: which said something about these disk benchmarks being bad for QD=1 workloads and were bad in simulating real-life scenarios but I wasn't able to understand what he meant.

Thank you for answering!

선풍기
  • 101
  • 1
  • 1
    I suspect you have only installed the Windows patch, which does not patch the second variant of Spectre, that requires a firmware update and/or a specific firmware patch yet to be released by Microsoft for your processor. Meltdown brought zero performance concerns, I would runt he PowerShell command, to verify you are actually patched against all variants of both Meltdown and Spectre. – Ramhound Mar 07 '18 at 18:26
  • @Ramhound I am specifically trying to test for Meltdown only, so I don't think the Spectre patch should play a role in it (effect of KPTI on performance) – 선풍기 Mar 07 '18 at 18:28
  • You are confused. Spectre's resolution to the vulerability is the one that had a performance hit. The resolution to Meltdown didn't have the same concerns. The performance hit was to the CPU, any changes to disk performance, likely has nothing to do with the patch itself. – Ramhound Mar 07 '18 at 18:29
  • 1
    ["In general, our experience is that Variant 1 and Variant 3 mitigations have a minimal performance impact, while Variant 2 remediation, including OS and microcode, has a performance impact. With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds."](https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/) – Ramhound Mar 07 '18 at 18:33
  • I have already answered two questions with regards to performance impact of both Meltdown and Spectre. I don't think we need another one. – Ramhound Mar 07 '18 at 18:34
  • Just so you know, you have generated an invalid conclusion, in order to determine that you had a performance increase you would have to run the benchmark several dozen times. Your sample size is extremely small. *You switched from saying you got an increase in performance to a decrease in performance.* Your results are extremely confusing, but unrelated, to the Meltdown/Spectre patch. – Ramhound Mar 07 '18 at 18:41
  • @Ramhound My understanding is that the Meltdown patch causes more strain on the CPU which in turn affects SSD performance. Since normally the SATA SSD speed is too slow, the CPU performance decrease caused by the constant syscalls isnt reflected onto the SSD R/W speeds. I did the stress test to dramatize the performance hit, and wasn't sure if it is flawed to do it this way. Yes, I am going to run it more times, just trying to see if I'm doing it correctly – 선풍기 Mar 07 '18 at 18:59
  • Meltdown nor Spectre should not result in any measurable performance problems with the CPU you describe. I provided you documentation to indicate, that it was Spectre, not Meltdown, that has the performance hit with regards to older CPUs. – Ramhound Mar 07 '18 at 19:13
  • It isn't "the CPU" that is affected; it is system calls. On every system call, kernel memory has to be mapped, then unmapped before returning. Small block random IO involves a lot of system calls, so will also be slowed down by the patch. – psusi Mar 08 '18 at 01:09
  • @psusi How is it that the patch improves performance? I did a 4KB QD32 Test, and the patch seems to have increased performance (did 5 trials for both, 30 minutes after system had booted, with no internet connection and background tasks) – 선풍기 Mar 09 '18 at 11:00
  • What is the CPU load during the test? If that goes up with the patch, then it may be that taking more time in the system calls makes it more likely that the task will still be running when some IO completes, so it will go to sleep less, allowing it to process the completion sooner and send down another IO request faster than it would had it gone to sleep. – psusi Mar 09 '18 at 18:19

0 Answers0