Comment 4 for bug 599352

There are two things to consider: physical memory to build an image before writing to disk and also available swap to do the write.

The kernel generates an memory image of the frozen system before writing it to disk.

Any pages in the zone regions that can be freed are freed. I believe this includes pages that are cached but not dirty (i.e. don't need writing back to disk).

Next, each zone is scanned an the number of present pages are totalled up, excluding the "nosave memory" (see later).
You can see the zone info in /proc/zoneinfo, the "present" field has the number of total pages present. The total excludes the "nosave memory" regions - this info can be seen by:

dmesg |grep "PM: Registered nosave memory:"

.. this tells you the nosave regions. These are pages that are marked in specific regions that do not need saving. These need to be turned into page sizes and taken from the "present" field from the zone info to give you an idea of how many pages need dumping in the final hibernate image.

However, the kernel calculates all of this in two sweeps, first the low-mem pages then the high-mem pages. It's rather complex to say the least.

Also, one needs to add in page meta information. This is calculated as: number of image pages * 8 and rounded up to the nearest page. In other words, for every 1M, we have 256 pages, and hence 2K of meta page info. So for a 1GB image, we have 2M of meta data too.

That's the image size. However, one needs to be able to allocate a hunk of memory for this image in physical memory before dumping to disk, and also have enough page space on swap for this image too.

Cheat Mode:

Instead of getting the calculator out and figuring out how big the swap needs to be, one can get a feel for the size by just doing a successful syspend and grepping through the output from dmesg and look for: "PM: Need to copy". This will tell you how many pages needed to be copied. However, this is only sensible for the desktop scenario you just hibernated. Some users may overload their system with many apps, in which case the hibernation image will be huge, in fact, there may not be enough free physical memory to generate an internal image before dumping it to swap.

The kernel will report the size of the hibernation image too, which can be grepped for. Look for "PM: Hibernation image created".

There may be mileage in shrinking the working set down by forcibly dropping pages, e.g.:

sync
sleep 1
sync
# Freeing the page cache:
echo 1 > /proc/sys/vm/drop_caches
# Free dentries and inodes:
echo 2 > /proc/sys/vm/drop_caches
# Free the page cache, dentries and the inodes:
echo 3 > /proc/sys/vm/drop_caches

But this maybe redundant. I've not experimented. And dropping caches is painful and if you don't sync it may cause data loss.