OSDev.org

Has anyone done testing on performance?

My queue was running at 17.6 million per second per core.
To get around the hardware issue I set cr3 on a system call, to make the kernel pages visible.
Then before returning back to userspace I had to set cr3 again to hide kernel pages.
My queue dropped to 2.2 million.
This is a drop of over 80%

The next step is to test with Page Present, then CPID

Tests using Page Present results were 5.6 million per second.

Anyone else have some results?

Ali

Hi,

tsdnz wrote:Has anyone done testing on performance?

I haven't (I'm still figuring out what I'm going to do for meltdown); but there are a lot of benchmarks/comparisons for Linux online (example).

tsdnz wrote:My queue was running at 17.6 million per second per core.
To get around the hardware issue I set cr3 on a system call, to make the kernel pages visible.
Then before returning back to userspace I had to set cr3 again to hide kernel pages.
My queue dropped to 2.2 million.
This is a drop of over 80%

This sounds almost like a micro-benchmark that's designed to measure the absolute worst case possible. These kinds of micro-benchmarks are almost entirely irrelevant. For example, if a web server spent 99.9% of its time processing disgustingly bloated server side scripting and 0.1% of its time on kernel system calls; then making kernel system calls 10 times slower would only make the web server 1% slower.

For micro-benchmarks that do nothing with the data, the obvious solution is to let the kernel do nothing with the data and avoid the "user-space to kernel space and back" switching completely.


Cheers,

Brendan

Brendan wrote:This sounds almost like a micro-benchmark that's designed to measure the absolute worst case possible. These kinds of micro-benchmarks are almost entirely irrelevant. For example, if a web server spent 99.9% of its time processing disgustingly bloated server side scripting and 0.1% of its time on kernel system calls; then making kernel system calls 10 times slower would only make the web server 1% slower.

For micro-benchmarks that do nothing with the data, the obvious solution is to let the kernel do nothing with the data and avoid the "user-space to kernel space and back" switching completely.


Cheers,

Brendan

100% Correct, only micro-benchmark, it was a surprising drop.

Ali

We did run UnixBench on one of our production servers before and after the patch. The tool indicated a performance decrease of a little over 20%.

We also routinely do timings on certain data batches that are run daily. We did not experience significant changes in run time there; other factors (like concurrent load, I/O performance, networking traffic etc.) drowned the Meltdown patch impact in lots of statistical noise.

Bottom line, yes the patch makes your CPU slower in certain ways. But unless you can measure that impact in your actual application, you shouldn't worry about it too much. Not to the point where you would compromise system security, anyway.

---

Corollary: Something I came to appreciate during the Amiga days, when there always was the next best and greatest accelerator board to be had (and I bought most of them), and people actually cared for the access time of hard drives etc. -- anything below a factor of 2 doesn't really matter that much in your everyday work.