Hacker News Reader

Comment by vanviegen | Hacker News Reader

So what's the alternative? Doesn't data dirtied by a write() experience the same or similar messy flushing behavior?

It depends. Are you using aio? O_DIRECT? write(2) gives you plenty more options and these days, it's no less efficient than mmap.

The whole idea of system calls being expensive is obsolete now that we're not using heavyweight software interrupts to implement them.

What the fuck do you think happens when you write to a mmap(2)ed page anyway? The kernel has to know the page is dirty somehow so that it can remember to flush it later. It learns about page dirtying by initially mapping the page read-only, letting the CPU fault when you try to write, marking the page dirty, and letting the write proceed.

You're entering the kernel either way.

"system calls being expensive is obsolete now" - utter nonsense. System calls are still expensive. Argument checking, copying data between user space and kernel space - none of that cost goes away.

It's far from nonsense. Everything that happens when you call a syscall nowadays is minimal compared to firing off interrupts to do the job. Memory operations are pretty cheap and the argument checking is probably only 20 or so instructions at most. A lot of the cost has gone away. If you still believe this, run dtrace on some random programs and be horrified over how many syscalls are being fired off.

Syscalls are hugely expensive. Not for those reasons, but because of the way they trash the cache, causing reduced performance for a long time after returning control to userspace. This is why to really achieve the performance the hardware is capable of, both for nvram ssds and for high speed network interfaces, you need to bypass the kernel completely. You can do a little better using calls that amortize the costs of the syscalls over multiple units of work, but even with the best optimizations it's still an order of magnitude less than what the hardware is capable of.

Sure. The problem is that intermediate-skill developers read comments like yours and just glean "lol, syscalls are slow" from them. They then go on to use mmap and kill MM performance. It's important to keep your audience in mind. Most developers do not write high-performance IO layers that talk directly to hardware. Most developers will blindly follow any sufficiently authoritative voice that tells them X is better than Y, which leads them to misuse powerful tools.

In the vast majority of cases, you want plain read and write. In the vast majority of cases, the overhead of jumping into the kernel is not your bottleneck. Simplicity counts for a lot.

Yes, simplicity counts for a lot. Staying in user space is simpler.

The reason LMDB can pack so much functionality into only 7KLOCs is because using mmap is much simpler than using read() and maintaining a user-level buffer cache.

In the vast majority of cases, developers need to profile their code if they actually care about performance - and fail to do so.

Reply on news.ycombinator.com