The next deep magic Linux program to change the world? Io_uring A few years ago developers knew eBPF as a handy way to build firewalls yet now it's used everywhere for everything. Get ready for io_uring to do the same. Most people don't know the first thing about Linux under the hood. Why should they? Linux, more so than most operating systems, just works. There's no need to poke inside it …
This post has been deleted by its author
As @teknopaul alludes, if you are only transferring data across the shared buffer it is not inherently more dangerous than read/write.
The article describes a circular buffer to speed I/O. It isn't hard to make something like that safe.
It isn't hard to make it really dangerous if you allow control information across it either. Communicate the index to a jump table and you should have your fingers broken.
Icon: you are playing with this.
The article is frankly nonsense, el reg?? . "The next deep magic Linux program to change the world? Io_uring"
It's not a program. It's a set of 4 or 5 syscalls that guarantees reads and writes are async and userland apis to make the syscalls accessible.
Modern Linux kernels have these syscalls. They are not very new.
https://en.m.wikipedia.org/wiki/Io_uring
Defines it correctly if you are interested in what it really is.
Ring buffers a very handy for super fast processing in general.
Check out Martin Fowler's description of the LMAX Architecture
Super fast if the computations will be quick*, otherwise the cascade puts the system to a crawl, which has and always will be the cautionary gotcha with any asynchronous system, ring based or otherwise. We've all been there as programmers... a bazillion things returning home all at once :-/. Either the system halts or the order of return makes everything worthless (_OR_ you did it correctly the first time like master you are!!!).
There's a popular saying in parallelism which is Why Wait? Well, typically you don't but if you're going to keep everything in RAM with lo_uring... you're going to need a LOT of RAM so you don't have to wait to ease the stack. I can see committing a bunch of financial or medical transactions quickly but, anything greater than that and resources will grow drastically.
*quick as in much quicker than the time it takes to round trip this post.
You're right in that operations should be quick, but really the idea is that subtractions from the buffer are asynchronous, so therfore aren't reliant on the buffer thread for synchronising.
Also, I have only utilised this in. NET for a trading app, so wouldn't like to comment on it's merit for more worthy stuff like health.
Generally computations are quick.
Hence the "latencies all developers should know" type articles.
There is no more ram requirement for async architectures, usually there is less, because each thread has a stack that needs to be swapped in and out. Heap requirements do not change.
That's how I first read it in the headline. I thought it was a tribute.
Of course all of this is done because Unix was originally designed without interprocess communications in mind, so that ended up requiring slow kernel calls, so now various patches are being made to get around that.
"there was only a narrow slow bridge of system calls between slow user space and fast kernel space processes"
To be pedantic, user space is not "slow" and kernel space is not "fast". Both are just as fast as each other, at computation. It's only the bridge that's slow - which data needs to cross, whenever user space wants to ask the kernel to do stuff like network or disk I/O.
Some projects solve the problem the other way round, e.g. VPP/DPDK where the network drivers and routing stack live entirely in user space.
in being right.
There are plenty of other shared memory/ring buffer implementations that date back to the y2k era. This may be another way, and have an edge depending on what/where you need to move stuff to. This article makes is sound like they just discovered fire.
Anybody ripping packets off a TOE card already knows this probably. The HPC crowd is going to toss this into the toolbox along with all of the other funny looking screwdrivers that mostly get used on special occasions.
This has been around for a while now. I had a play with this way back before covid.
It's a bit of a bugger of an api so it's only worth it if you want really crazy speed.
I was maxing out my Ethernet hardware with plain old read() write() so it's not clear that there will be lots of practical uses in a PC.
Network hardware folks might find it more interesting.
True, and true.
It's only really interesting at the very top end of I/O - file servers, databases, HPC etc.
That said, because of that it also means that certain things that would otherwise need to be kernel drivers for performance, can be done in userspace instead.
Which is nice.
I have a pair of switches on the bench at work. They cost about £10,000 each. They have 28 x 10Gb ports and two 100Gb links each. They boot a rather strange Debian for the control plane and the good Lord knows what does the data shifting plane is running - they are running Dell OS10.
There is a good chance that io_uring and co will blur the old style control/data plane on network hardware and we will get really converged thingies where the switch, router and server (and data) are properly one thing.
Not yet, despite the bollocks from "hyper converged".
Seymour Cray's CDC 6600 used this idea around 1970, more than 50 years ago. The 10 PPU (Peripheral Processor Units; each 4K words of 18 bits) assignable by the OS for control of devices (disk, tape, etc.) communicated with user programs running asynchronously on the CPU using circular buffers in shared main memory. It was possible to read or write an entire 10.5-inch reel of magtape (~30MB; RAM totaled ~2MB) without stopping the tape except at the end.
Yeah, well, we don't have large 1970s Crays on our desks, in our pockets, in our bags, and in our 1U racks in 2023. So we'll make do with this.
I love the history, don't get me wrong. But that doesn't make today's implementation, for today's computers and users, any less interesting or useful or relevant.
C.
Well, sort-of. There was a high-speed data link between a PPU and a terminal data concentrator (of whatever sort you were using). Our Uni had a PDP-8 with a scad-load of 110- and 300-baud serial lines coming in; it acted as a front-end processor/data concentrator. (It even communicated with the OSes on our two CDC mainframes; typing TRAFFIC at the PDP-8 fetched statistics from the mainframes and printed them for you, so if the systems were heavily-loaded, you could decide to do your on-line work later. But that was a purely locally-implemented feature.)
And IBM has pioneered the process isolation, system isolation, image isolation and application specific accelerators in the mainframe space that we got only recently or are getting just now in the x86_64 space.
Yes, we should remember the history of the inventions, but an idea without an implementation isn't really useful.
Fundamentally looks the point in the async modus operandi against the sync mode of syscalls. I wonder how interacts and what is the implications on scheduling policies and other areas that do need muted ops. . We have seen these debates on async vs sync in a lot areas from real time systems that forcibly waste cpu cycles to guarantee time share to complete async work done in frameworks like ngix. I guess there will be use case for each.
Phoronix had a bit last week, here https://www.phoronix.com/news/Linux-LPC2022-io_uring_spawn
Includes John Tripplett's presentation and a pdf slide deck...
I belong in the group "Most people don't know the first thing about Linux under the hood but nevertheless enjoy following the devs work through the kernel changelogs as well as the public mail lists.
A privilege I did not had for my past +30 years with Microsoft... two very, very different worlds.
I'm currently trying to build some documentation that shows how Fuzix works. Basically hyperlinking the code with explanations. Perhaps not the best place to start as there's a lot of cpu dependent code. Its quite an eye opener and I hope it will be a useful educational tool. I may move onto Linux when done.
It strikes me that the approach should be generalized for any device that can handle asynchronous IO, not just file systems... and I'm hoping they've either already done that or have plans to do so in the future.
Despite the Linux mantra, I can tell you with emphasis that the world is not comprised entirely of files and devices.
As revealed this week, Microsoft chose to port eBPF into Windows rather than try to duplicate its functionality with its own program. io_uring may become the next Swiss-Army tool for Linux developers.
Windows is obsolete. It carries on as a majority desktop operating system, for the time being, only because of the momentum of its massive installed base. Everywhere else, it is in decline and everyone everywhere agrees that it is a developmental dead end. The cloud runs on Linux. Mobile runs on Linux (Apple variants notwithstanding). Containers run on Linux. Software-defined storage/networking/etc. runs on Linux.
In the data center and in the cloud, no one chooses Windows Server anymore, except to run legacy software. Windows Mobile is dead. Windows Embedded is dead.
Microsoft would do well to continue porting Linux technologies to Windows, but at the same time working to phase out Windows entirely.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
