3 ms·

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 7mo ago
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 7mo ago
  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 7mo ago
    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 https://man7.org/linux/man-pages/man2/mmap.2.html
    - namibj 7mo ago
      mmap is also for non-disk-backed memory: Your link refers to https://www.kernel.org/doc/Documentation/admin-guide/mm/hugetlbpage.rst 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 7mo ago
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 7mo ago
  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/ https://www.bitflux.ai/blog/memory-is-slow-part2/

nixon_why69 7mo ago

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 7mo ago
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 7mo ago
  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 https://man7.org/linux/man-pages/man2/mmap.2.html
  - namibj 7mo ago
    mmap is also for non-disk-backed memory: Your link refers to https://www.kernel.org/doc/Documentation/admin-guide/mm/hugetlbpage.rst 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 7mo ago

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 7mo ago
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/ https://www.bitflux.ai/blog/memory-is-slow-part2/