# s2disk aggressive swapping/throw away

## devsk

Folks, is there a way to tell s2disk to not throw away resident pages and/or copy all of swap contents back to RAM instead of slowly bringing them back?

After resume things are sluggish to say the least. And 'free' tells why.

```

$ free

             total       used       free     shared    buffers     cached

Mem:      12299120    3946108    8353012          0      73876     412216

-/+ buffers/cache:    3460016    8839104

Swap:     12697596    4508580    8189016
```

Normally, my system doesn't have any swap use because, as u can see, I have 12gb of RAM. But after a s2disk cycle,  there is tonne of stuff of in swap. I have following settings in /etc/suspend.conf:

```
$ cat /etc/suspend.conf 

snapshot device = /dev/snapshot

resume device = /dev/sdb1

image size = 10200000000

suspend loglevel = 10

#compute checksum = y

compress = y

#encrypt = y

early writeout = y

#splash = y
```

I have made image size large to try and prevent s2disk from throwing away pages, it still only writes about 4GB of image during suspend. Combining with compression, I am not sure why it needs to discard pages or leave them on swap.

So, here is what I want: A simple implementation which takes RAM, compresses it and writes it out to free areas of the swap partition, and upon resume, brings everything back to RAM. Even without compression, I have given it full 12GB of swap to work with. So, writing the image out should not be a problem space wise.

Any ideas on how I can tell s2disk to do that?

----------

## devsk

anyone? nobody uses s2disk?

----------

## EatMeerkats

http://tuxonice.net/index.php does exactly that  :Smile: 

----------

## devsk

 *EatMeerkats wrote:*   

> http://tuxonice.net/index.php does exactly that 

 Is tuxonice still actively developed? I prefer in-kernel features because patches don't get tested that much for stability.

I have tried tuxonice in the past and inadvertently, it fails over long uptimes.

----------

## Hu

You could try manually cycling swap off and back on after you resume, which would force the kernel to page in all pages swapped to that device before it can be considered "off".  However, this is a crude approach which will page data in without any regard to whether it might be useful to preload it.  Data which had been swapped for hours before hibernation is probably not useful to bring back, for example.

----------

## devsk

 *Hu wrote:*   

> You could try manually cycling swap off and back on after you resume, which would force the kernel to page in all pages swapped to that device before it can be considered "off".  However, this is a crude approach which will page data in without any regard to whether it might be useful to preload it.  Data which had been swapped for hours before hibernation is probably not useful to bring back, for example.

 That's what I am trying to avoid. It resumes so slow that after resume, its churning disk like crazy. And it still has gigs of stuff in swap. Whereas if it loaded everything back from the disk to RAM in one chunk like it restores the pages it thinks are minimally required, it would be much more efficient. Its about sequential b/w vs. asking kernel to load swap back on demand as needed basi. For example, after resume, X has to be posted, so its pages have to be brought in, but then KDE's processes' pages have to be brought in as well but those pages are now in a different location. All this makes the head of the disk to move from one location to the other and back, thus reducing the speed. If all pages were brought back in one continuous sequential flow, it would load it all back in within seconds.

Another problem is that it discards many pages while saving the image, no matter what image size I ask for. It creates about 2GB of image, whereas the total RAM occupancy is about 6GB. I think this is critical step because during restore its just restoring these 2GB and leaving the rest to kernel to restore on demand. So, the damage has happened during saving of the image.

----------

## devsk

bug filed: https://bugzilla.kernel.org/show_bug.cgi?id=26452

----------

## pigeon768

 *http://www.kernel.org/doc/Documentation/power/swsusp.txt wrote:*   

> Q: After resuming, system is paging heavily, leading to very bad interactivity.
> 
> A: Try running
> 
> cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
> ...

 

----------

## devsk

 *pigeon768 wrote:*   

>  *http://www.kernel.org/doc/Documentation/power/swsusp.txt wrote:*   Q: After resuming, system is paging heavily, leading to very bad interactivity.
> 
> A: Try running
> 
> cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
> ...

 I hate to do what I don't understand. Care to explain what that 'cat' does?

----------

## boerKrelis

If you want to see what it does, execute the inner commands first.

/proc/pid/maps gives you a map of the programs' address space, with mappings to libs and all. Filter out the libs/files, and cat them to > /dev/null, to make sure the pages enter the memory cache.

I use pm-utils with pm-hibernate instead of s2disk. pm-utils has a scripting facility. So I just turn on swap just before hibernation, and turn it off afterwards. Sluggishness is gone in about 15 seconds (and this is on a slow laptop).

----------

## devsk

There is indeed a bug found in s2disk while analyzing the symptoms.

Its much better now.

----------

## Hu

After reading the referenced entry in the kernel bugzilla, it is not clear what you changed to make things "much better."  I see that you found some sort of integer truncation bug.  Presumably, fixing that was a prerequisite to making things better.  Could you post or link to the exact source code change you made?

----------

## devsk

```
$ cat ~/Installs/suspend-0.9-rounding_fix.patch 

--- suspend.c.orig      2011-01-13 20:41:21.346666833 -0800

+++ suspend.c   2011-01-13 21:48:32.618044216 -0800

@@ -308,7 +308,7 @@

        return ioctl(dev, SNAPSHOT_FREE, 0);

 }

 

-static int set_image_size(int dev, unsigned int size)

+static int set_image_size(int dev, unsigned long size)

 {

        int error;
```

There you go! Its needed if you have 8GB or more RAM. Note that kernel implementation of hiberantion does an atomic copy in RAM itself, so your image can't be greater than 1/2 of your RAM.

----------

## Hu

Thanks.  Would you mind filing a Gentoo bug to have the sys-power/suspend build bumped to include that patch?  Large memory systems are becoming more common, so I expect others will hit this bug soon if they have not already.

----------

