
Thanks to Google Summer of Code student Zhao Shuai,
Haiku now has support for a swap file.
"As of revision 27233 it is enabled by default, using a swap file twice the size of the accessible RAM. The swap file size can be changed (or swap support disabled) via the VirtualMemory preferences. Swap support finally allows building Haiku in Haiku on a box with less than about 800 MB RAM, as long as as the swap file is large enough. [Ingo Weinhold] tested this on a Core 2 Duo 2.2 GHz with 256 MB RAM (artificially limited) and a 1.5 GB swap file. Building a standard Haiku image with two jam jobs (jam -j2) took about 34 minutes. This isn't particularly fast, but Haiku is not well optimized yet." The swap implementation borrows heavily from that of FreeBSD.
Member since:
2006-01-30
It's important to explain why "some OS" on the event of a crash dumps the whole system memory over the paging file: because it's pre-allocated and, at some point, reliable (ie: safe to write to).
There could never be something unexplained or uncotrolled at kernel space. If something odd happened at kernel space, it (the kernel) can only be trusted to a minimum, so trusting it to allocate another file could be disastrous and render the whole system corrupt or unusable, so this design of using a pre-allocated file would be the safest.
Back to the matter at hand, the fixed value of twice the RAM is completely out of parameter, but you have to start somewhere, so it's understandable.
I would choose no hard disk paging, ever, for a few reasons: it's simpler (and simpler is always good) and you got the "how much RAM you have is exactly how much you can expect to load on your system" approach (a lot easier for everyone: users, developers, admins, ...).
I have an idea: use disk paging only after the system generated a baseline on how a particular system behaves. I think it's the smartest way to do that.