[nasretdinov]

In Linux the default swap behaviour is to also swap out the memory mapped to the executable file, not just memory allocated by the process. This is a relatively sane approach on servers, but not so much on desktops. I believe both Windows and macOS don't swap out code pages, so the applications remain responsive, at the of (potentially) lower swap efficiency

[superjan]

Don’t know about Macs, but on Windows executable code is treated like a readonly memory mapped file that can be loaded and restored as the kernel sees fit. It could also be shared between processes, though that is not happening that much anymore due to ASLR.

[inkyoto]

> In Linux the default swap behaviour is to also swap out the memory mapped to the executable file, not just memory allocated by the process […] I believe both Windows and macOS don't swap out code pages, so the applications remain responsive, at the of (potentially) lower swap efficiency

Linux does not page out code pages into the swap. You might be conflating page reclamation with swapping instead.

In Linux, executable «.text» pages are mapped[0] as file-backed pages, not anonymous memory, so when the kernel needs to reclaim RAM it normally drops those pages and reloads them from the executable file on the next page fault once they are accessed again (i.e. on demand) rather than writing them to swap.

In this particular regard, Linux is no different from any other modern UNIX[1] kernel (*BSD, Solaris, AIX and may others).

[0] Via mmap(2) in argv[0], essentially.

[1] Modern UNIX is mid-1990's and onwards.

[nasretdinov]

Yes, you are correct, I wasn't precise enough. It doesn't make sense to swap the existing code pages, they are just unmapped. (And that's the reason why you get "text file busy" when doing scp over the file: since the OS relies on the fact that the .text pages can be safely unmapped it needs to guarantee that they stay read-only)

[man8alexd]

It seems to be a persistent myth. The Linux kernel explicitly excludes active VM_EXEC pages from reclaim.