The article's subheadings suggest this is AI slop. Seeing a section titles "The Production Symptom" is a Claudism in itself.
You're absolutely right.
We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
11–20 of 26 posts
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#12The real issue here is there's a part 2 (linked at the end of the article) where they get the io_uring implementation to be twice as fast as mmap. So it's a clickbait title for a part 1, which gets resolved in part 2.
So they crunched out 2 articles, one of which is just ragebait. And they both seem LLM written. Maybe they have some cool advice, maybe not... but it's not a format I enjoy reading.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#13> The internet is full of posts declaring io_uring wins over mmap.
Internet is also full of idiots not having done their homework.
Blindly throwing io_uring for mmap and hoping for better perfomance in a highly concurrent environment is a recipe for thread contention and latency spike.
Add to that the kernel lock contention on mmap. Later kernels have tried to increasingly mitigate this. But significant latency on kernel lock contention still exists.
Try mmap + numa like pinning (from software atleast via hashing the work id) and always have the same mmap be used from the same node. This usually yields better latency compared to throwing wonder weapons.
Our database Dip uses mmap burst for opening massive amounts of mmaped kv engine files along with numa pinning of the same mmap kv engine file to the same core so as to reduce cross cache contamination and page cache relocation.
io_uring (available only in more modern kernels) has so far only increased Dip's latency. Hence we have no reason yet for using it. It is a net negative for our usecase.
Use io_uring where appropriate and don't expect every mmap replaced by io_uring to do wonders.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#14The real issue here is there's a part 2 (linked at the end of the article) where they get the io_uring implementation to be twice as fast as mmap. So it's a clickbait title for a part 1, which gets resolved in part 2. So they crunched out 2 articles, one of which is just ragebait. And they both seem LLM written. Maybe they have some cool advice, maybe not... but it's not a format I enjoy reading.
I find a lot of LLM articles to be hard to read, but since this one was pretty "straight to the point", I found it to be okay and got the important information across.
The title "The Linux reality check" made me groan, though. LLMs (Claude?) seem to love this phrase.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#15The article's subheadings suggest this is AI slop. Seeing a section titles "The Production Symptom" is a Claudism in itself.
That heading is the smoking gun.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#16There is a pattern in software engineering of: * Project exists * New employees come up with idea for efficiency improvement * Months spent implementing. Old codepath becomes legacy. * New thing now has extra features bolted on during build. * Efficiency of new thing turns out worse than original, but now the new features and 'less technical debt' are the drivers. * New thing launches, old thing deprecated, but there…
Second System Effect
https://en.wikipedia.org/wiki/Second-system_effect
Coined by Fred Brooks in "The Mythical Man-Month" in 1975.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#17There is a pattern in software engineering of: * Project exists * New employees come up with idea for efficiency improvement * Months spent implementing. Old codepath becomes legacy. * New thing now has extra features bolted on during build. * Efficiency of new thing turns out worse than original, but now the new features and 'less technical debt' are the drivers. * New thing launches, old thing deprecated, but there…
Then they fix the new thing implementation[1] and realise the original gains that were promised
[1](https://www.conviva.ai/resource/making-io_uring-actually-fas...)
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#18Yay, first article (for me!) that i actually click on because the title is interesting, and then it puts me off because it's LLM generated. By the way, what does Rust have to do with their problem? Is Rust simply bad at io_uring? :)
...given article being LLM slop their code probably also was
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#19The real issue here is there's a part 2 (linked at the end of the article) where they get the io_uring implementation to be twice as fast as mmap. So it's a clickbait title for a part 1, which gets resolved in part 2. So they crunched out 2 articles, one of which is just ragebait. And they both seem LLM written. Maybe they have some cool advice, maybe not... but it's not a format I enjoy reading.
I find a lot of LLM articles to be hard to read, but since this one was pretty "straight to the point", I found it to be okay and got the important information across. The title "The Linux reality check" made me groan, though. LLMs (Claude?) seem to love this phrase.
The problem is not the LLM writing. The problem is the ragebait title which is unsubstantiated, because of part 2. And they know that because they published it in two parts.
This is basically how you write fake news. And you only publish like this for extra clicks.
Re: We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower
#20The real issue here is there's a part 2 (linked at the end of the article) where they get the io_uring implementation to be twice as fast as mmap. So it's a clickbait title for a part 1, which gets resolved in part 2. So they crunched out 2 articles, one of which is just ragebait. And they both seem LLM written. Maybe they have some cool advice, maybe not... but it's not a format I enjoy reading.
I wouldn't call it ragebait. Trying to optimize things only to end up with worse performance seems to be a rather common outcome. Understanding why that happened is key to overcoming it.
I agree that it should have been a single article though.