Meltdown KPTI patch affect on Ardour

Hi :slight_smile:

Does anybody have any idea of the impact the Intel hardware bug (Meltdown) mitigation (Kernel Page Table Isolation) patch has on Ardour performace ?

I guess Ardour needs to constantly make kernel calls to read / write the sound card and disk and these calls will be slower on Intel chips because of the KPTI patch in current kernels. Is that so ?

I guess I could always disconnect from internet and disable KPTI with the boot option: pti=off

AMD is going to get a huge boost in sales because of this Intel bug. Those Ryzen and Epyc processor suddenly seem much more desirable :slight_smile:

AMD has it’s own bugs as well. There was a discussion on this (Bugs in CPUs) somewhere on these forums a bit back IIRC(Which you may have been a part of, but to lazy to check), short version everyone has issues.

 Seablade

Low latency audio I/O is affected. As for how much that remains to be seen.
I don’t recall where I’ve seen numbers (perhaps some 34c3 talk): Those were 1200 CPU cycles instead of 900 cycles. That would be short compared to msec cycle-times.
Reading audio-files is not realtime and the buffer is quite large (10 sec by default).

Windows versions may be disproportionately affected more. Ardour’s cross-thread signaling on Windows uses sockets which may or may not make a syscall on Windows (my windows-fu is lacking).

On Linux at least, Ardour does not use system calls to read/write to the sound card. We memory-map the device and write directly to its buffer. We use a system call to wait for the device to be ready for I/O. Disk I/O costs are already vastly greater than anything KPTI will introduced so the effect there is negligible.

Ok, I’m glad to hear that on Linux we might not even notice the effects of the KPTI patch :slight_smile:

I realized that what I wrote is not strictly correct. I think that ALSA still requires a system call to notify the device driver about how much data was read or written.

Google have also recently reported that they have a software workaround which does not significantly affect performance.

@anahata: They have a software workaround for one of the issues. In relation to KPTI, the blog states: "Performance can vary, as the impact of the KPTI mitigations depends on the rate of system calls made by an application. " which I think is effectively what is being said by others in this thread. As Paul alluded to, there are other things which can consume far more CPU cycles than this patch does. (and are just a part of doing audio work on a general purpose machine, and have always been so). I haven’t noticed any issues using Windows 10 or macOS either. In fact, if I’m correct in thinking that macOS 10.13.2 is patched, then that happened before all the media hype, and I didn’t even notice (though not a very scientific evalutation I’ll admit…)

On Linux kpti can be disabled using nopti at boot time, if you are confident your audio workstation is safe.