LWN: Comments on "The phaseout of the mmap() file operation"

The odd behavior of /dev/zero

roblucid — Tue, 14 Oct 2025 21:07:15 +0000

/dev/zero implementations generally has a single page that's cleared and the virtual memory efficiently merely maps that zero page that's shared frequently and COW means writes cause a page fault to get a free page to be dirtied. Once memory over-commit became common, applications
would rely on sparse memory structures not actually using much memory that they had allocated. so there was no going back to the older way where
actual physical swap space was allocated to back what was asked for, because that broke stuff.

The big change came with shared libraries, prior to that it wasn't uncommon to link applications commonly used together and have the command name select functionality, thus saving page faults and sharing memory better; even later GNU fileutils was doing the same sharing common code.

The odd behavior of /dev/zero

eklitzke — Mon, 29 Sep 2025 21:53:13 +0000

/dev/zero is actually one of the required device files (as well as /dev/null and /dev/console) according to POSIX, so it should always be available. The behavior of mmaping it is of course implementation specific.

The odd behavior of /dev/zero

iabervon — Fri, 26 Sep 2025 12:52:51 +0000

I assume that the weird special effect in /dev/zero is that the traditional way of getting anonymous pages (before MAP_ANON) was to mmap /dev/zero; data you write to pages you get from /dev/zero neither goes back into /dev/zero nor gets turned back to zeros, so it's effectively anonymous memory, and that was the idiom until it became standard to not have all of a process's early memory allocation done with sbrk and it was too much of a hassle to rely on /dev/zero being available, and needing to open it before you could allocate memory.