# Why does the OS need to copy all RAM into HDD for hibernation?

my question is theoretical in computer OSes, specifically about hibernation.

As far as I know, hibernation (ACPI state S5, is that right?) involves writing into the hard disk all the data needed to restore RAM when OS os booted up again. OK this sounds good to me.

But, I remember the old times of Operating Systems class when the teacher explained the differences in memory management between OSes. Windows and Linux kernel both use virtual memory: all pages are initialized into swap, then loaded into RAM when needed so they can be relocated at any time.

I also know that memory pages are not immediately flushed to swap, but are kept in memory for a certain amount of time, or when there is the need to load a page from swap and all memory pages are dirty

My question is: Why does Windows need to store a separate hiberfil.sys file with all RAM dumped inside since all pages should be already present in swap file (and hibernation would simply mean flushing the caches and stopping the computer) and almost all clean after a prolonged inactivity?

The same, why does Linux explictly say it's copying pages to swap partition? When I simply suspend the system, it takes a couple of seconds of continuous disk access before halt (perhaps kernel flushing caches), but when I want to hibernate it takes the same time it takes to restore.

Am I missing something about kernels?

-
Pagefile.sys is not always used by windows, it is reserved hard drive space to be used "if" needed. With Vista and W7 and plenty of installed memory PF is not used much if at all. –  Moab Dec 4 '10 at 18:00

Some of what you're describing sounds less like virtual memory and more like a disk cache, where the operating system keeps in-memory copies of the data it reads off of the disk, in case an application wants to read it again. In this scenario it may also delay writing "dirty" pages back to the disk in order to increase efficiency by writing a bunch of pages all at once.

Virtual memory is the other way around -- data is written into RAM first, and only into the swap file if the kernel needs to free up that RAM for some other purpose. (Not every bit of memory necessarily has a corresponding space in the swap file; otherwise you couldn't have a swap file smaller than your RAM size.) Conventional thinking is that this is the way it needs to be; it would be too expensive to keep copying the RAM to disk all the time when you don't need to. Think about how slow your computer runs when you're running lots of memory-hungry programs and it has to start thrashing the swap space.

That said, there are some experimental research operating systems that work more like you describe, with some complex rules for copying the memory back to disk at regular intervals, and the result is that there's no need for hibernate -- you can pull the plug on the computer and lose maybe 30 seconds of work. Check out CoyotOS, CapROS, or EROS if you're interested theoretically. I don't know what their performance is like, or what other downsides there might be to such a strategy, but when you factor in crazy things like memory shared with your video card or other devices, I'd imagine it's difficult to get it working properly for all cases. As far as I know, no production operating system does this sort of thing.

-
I think copy the pages in RAM to the free space in pagefile at the hibernating time is much faster and space efficient than using a seperate hibernate file –  Lưu Vĩnh Phúc Sep 13 '13 at 4:22

The misunderstanding here is that not all RAM contents are swappable to disk.

User processes have dedicated swap space, but system does not. That is because many parts of the system are never swapped out, and the ones that are swapped out are simply erased from memory as not needed any more (not written out). System in this case includes the kernel and drivers and all data used to control processes (such as virtual memory segment table).

The hibernation file is written with all the data that is required to duplicate the system state. This is far from being equal in size to the RAM, as only occupied memory is written out.

Saving and restore take about the same time since the same data needs to be read as was written out. On disks where reading is much faster than writing, such as SSD, restore will be much faster.

-

Your page file could be smaller, bigger, or the same size as your RAM. Some people even (mistakenly) turn it off. So Microsoft decided to create a separate file that is guaranteed to be the same size as the RAM, and that can be read and written to at start-up and hibernate respectively. As for Linux, I would assume the same logic.

EDIT:

And as harrymc points out in his answer, it's to maintain system state.

-
In Linux, swap partition is often sized as double the RAM. Snapshotting the list of active memory pages (the only ones you need to copy into RAM during resume) would speed up a lot IMHO. I assume pages are already in swap, then using the list of those that were active would bring the system to its exact previous state and reduce page-miss events –  djechelon Dec 4 '10 at 17:19
Speed at the cost of reliability ? Quite often people turn off swap. So you expect the OS to compare RAM contents to swap contents and then write only the ones not present ? I'd imagine it'd be a lot faster to dump the entire RAM contents than go about searching hokeypokey. –  Sathya Dec 4 '10 at 17:31
Having double the swap space as amount of RAM is a leftover from an era when 256MB of RAM was a lot. Nowadays it is (usually) completely ridiculous to allocate a whopping 8GB of swap. In case of a memory leak, that can be quite detrimental to a system's performance. Having to allocate the same amount of swap as RAM just for the ability to hibernate is silly, and one of several reasons I don't use hibernation on Linux. –  oKtosiTe Dec 4 '10 at 18:27
@sathya: I don't mean comparing the whole contents of the RAM. Just having a table of which pages are in RAM, write to swap, and upon restore read it and restore only the pages listed ;) –  djechelon Dec 4 '10 at 18:32