|
|
Log in / Subscribe / Register

Does it actually work?

Does it actually work?

Posted Apr 11, 2025 4:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Does it actually work? by khim
Parent article: Three ways to rework the swap subsystem

> Yet, somehow, it works fine with macOS or Windows. That's what makes things really weird: Linux claims that it has very efficient and quick swap subsystem yet, in practice, it works like a crap.

Windows doesn't do overcommit (unless you REALLY try with MEM_RESERVE flag for VirtualAlloc). If a program allocates RAM, then there is a page in memory or in the swap file to back it. This naturally limits the amount of memory that has to be materialized out of thin air if there's a "bank run" on uncommitted RAM.


to post comments

Does it actually work?

Posted Apr 11, 2025 8:21 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

That's entirely different kettle of fish. You can disable overcommit on Linux, add 1TiB swap on the 4GiB desktop… and it would still become absolutely unresponsive if you would run two rustc processes that try to use 20GiB each.

And yes, miracles are impossible: if you would try to run some process that needs 1TiB of RAM while physically there are only 1GiB then even on macOS or Windows you would have to wait, most likely, till the heat death of universe.

But using 2x, 3x, 10x more RAM than your machine does have, physically? With dozen of apps? That's Ok: system is becoming more and more sluggish but it stays usable. On Linux using even 2x more is, normally, a prelude to hitting “reset”.

Does it actually work?

Posted Apr 14, 2025 8:37 UTC (Mon) by taladar (subscriber, #68407) [Link]

It is really less of a factor how much you overcommit and more how much of the overcommitted memory is in active use. Once that goes beyond your physical memory you have a problem no matter what you do with swap.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds