[nickelpro]

mmap is also relatively slow (compared to modern solutions, io_uring and friends), and immensely painful for error handling.

It's simple, I'll give it that.

[nixon_why69]

Page faults are slower than being deliberate about your I/O but mapped memory is no faster or slower than "normal" memory, its the same mechanism.

[namibj]

Nah, usually can't have huge pages. Almost certainly can't have giant pages. Can't even fit all L3$ capacity into the L2 TLB if done via 4k pages...

[nixon_why69]

I hadn't thought of that but apparently Linux at least has had support for a while, according to manpage? https://man7.org/linux/man-pages/man2/mmap.2.html

[namibj]

mmap is also for non-disk-backed memory:

Your link refers to https://www.kernel.org/doc/Documentation/admin-guide/mm/huge... ,

which contains this tidbit:

> If the user applications are going to request huge pages using mmap system call, then it is required that system administrator mount a file system of type hugetlbfs::

Note this otherwise has semantics similar to tmpfs; notably, it's usage is mutually exclusive with being able to supply a disk file fd to mmap!

[hyc_symas]

On BSD, read() was already implemented in the kernel by page-faulting in the desired pages of the file, to then be copied into the user-supplied buffer. So from the first time mmap was ever implemented, it was always the fastest input mechanism. (First deployed implementation was in SunOS btw, 4.2BSD specified and documented it but didn't implement it.) Anyway there's no magic to get data off a device into memory faster, io_uring just lets you hide the delay in some other thread's time.

[nickelpro]

mmap is slow because stalling on page faults is slow. Your process stalls and sits around doing nothing instead of processing data you've read already. You can google the benchmarks if you like. io_uring wasn't built just for kicks.

https://www.bitflux.ai/blog/memory-is-slow-part2/