How does that make it not a bug? They've repeatedly responded to the "openbsd is slow" meme by pointing out that they do not have the time to benchmark anything, and if people do find slow things they should submit bug reports so they can be fixed. Nobody has ever submitted such a bug report.
I mentioned it on the mailing-list a long time ago, when I was more naive about these things. They said I should submit a patch. However, adding virtual syscalls is a non-trivial undertaking, and I'm not experienced enough with kernel internals, which will require wide-ranging changes, including adding special mapping support, hacking the program loader, and tweaking the clock subsystem.
Plus you also have to hack userspace. Most importantly you need to add VDSO support to the linker. Refactoring time(2) would be easy, but for higher granularity clocks--gettimeofday(2) and clock_gettime(2)--you need to make careful use of RDTSC and similar instructions for each architecture. _And_ you need to be able to test it well because of synchronization issues on older platforms. On x86, for example, RDTSC is synchronized, but for a long time it varied across cores, and when Intel and AMD fixed that there was a still a small product window where it could vary across CPU packages.
And the part where the developers explicitly say being slower than necessary is a bug and should be reported as such means it is a bug. This honestly is not complicated.
Got a link to those benchmarks? Did anyone file a bug report?
>But commercially and at scale I run Linux
Wouldn't netbsd be a better option?