Speaking of fast connections, has there been anything looked in to for the io-uring linux interfaces (falling back to the old methods on older kernels)? It’s been shown to have quite some advantages in a lot of contexts over traditional patterns. I’ve been using it (outside erlang) for a few months now and it is quite nice when trying to eek out performance when the I/O interface actually becomes a bottleneck (can have much fewer syscalls!).
We have looked at it and realized that it is a lot of work to get done. I’m sure we’ll get around to it eventually, but not any time soon.
4 Likes
Yeah that it is, it is a significant change from the older API’s, and not always worth it for some work (though not worse by any stretch), but it definitely is a lot faster in some things (especially multi-waits).
Even just a low level binding exposing it could be useful though.
3 Likes
We did too, as it closely reminds FreeBSD’s kqueue. But one of the major benefits with io_uring is to also avoid extra read/write syscalls, and integrating this into ERTS appears to be challenging.
2 Likes
I’ll just stay on FreeBSD 
Yes in theory io_uring could be faster than kqueue. But comparing this is easily driving into apples and oranges area.
But for all who care about this kind of IO performance: move to FreeBSD today, kqueues are supported by Erlang since a long time and are well tested and around for long. Will not get started with other FreeBSD advantages to avoid this degrading into a Linux/BSD flamewar.
Its just about being pragmatic: there is a choice available today which will improve your performance vs. some feature which might be coming later if at all (since it doesn’t fit nicely to ERTS).
The only price is that you need to drop Linuxisms from your surrounding infrastructure, but improving portability among Unix alikes is a nice improvement overall because it makes one flexible. This Unix compatibility thing was once a major industry effort until Linux came along and got dominant and for many seem to be the only solution
4 Likes
I would rather improve ERTS to support io_uring than try to bring another OS into tight corporate environment. Plus, it benefits the entire community.
5 Likes
Fortunately my company was always on BSDs starting with commercial BSDI (which led to me working for them until they were bought by WindRiver) the FreeBSD. Knowing kernel internals pretty well. Therefore we stayed on FreeBSD as the default choice of Unix. And even the TCP (and USB) stack on GRiSP is from FreeBSD.
Agree that its hard to introduce in large corporations (like its hard to introduce anything) but here are also many at smaller shops or just starting. And for them its a good choice for better Erlang I/O performance via kqueue which is available right now.
Tip to small companies: don’t go always with the default tools from the large corporations, sometimes they can slow you down and can prevent disruptive potential.
Once upon a time, there was this startup serving superior chat to half a billion users on a bunch of FreeBSD servers running Erlang. Seemed to have served them well to get there and get bought
9 Likes
Aren’t WhatsApp using FreeBSD anymore? Must admit that was the primary reason I was interested in trying it one day 
If you’re not @max-au did you notice much difference when you changed? As much as I think FreeBSD is awesome, it’s definitely a good thing for Erlang if WhatsApp are still managing to get the same sort of performance by running on Linux 
1 Like
They moved to Linux at some point after being bought by Facebook. Reason being, as best I recall, that Facebook thought it sensible to have homogenous hardware (they already had their own datacentres with many relatively low power Linux servers vs a relatively few high power FreeBSD servers that WhatsApp had grown up with). It caused a few challenges to migrate.
This is all gleaned from a talk from one of the WhatsApp folk and comes with the caveat that I may have misremembered.
5 Likes
Nice find Phil - I missed that talk!
That’s even more interesting - WhatsApp runs on servers capped at 32GB of RAM!!
I’d love to see a book from the WhatsApp team - I bet we’d learn so many cool things!
6 Likes
I’ve looked inside io_uring and tried to make a simple driver for erlang.
Yes, there is lot of work and it seems that io_uring should be instead of epoll if we want to achieve lockless design without mutex on each step.
3 Likes
It seems more language runtimes are adopting it becauuse of the performance benefits. I am not deep enough on the subject but it seems this is the future of I/O on Linux.
I believe we would not benefit that much (8x in throughput would make the BEAM the best in class probably…) but it seems like something worth of investment at least.
For now I’ll have to be glad to spectate on the matter 
8 Likes