Bug 34102

Strictly speaking, this is not a regression, because the radeon driver with
KMS has never worked correctly for you in this respect, right?

Now, while the ultimate fix would be to rework device drivers so that they
don't allocate memory from their ->suspend() callbacks, it's not quite
realistic to expect that that's going to happen any time soon.

For this reason, I'll try to provide a workaround for you.

It depends on the view point. Compared with the pre KMS radeon driver this has been a regression for me.

Thanks for trying to provide a workaround. I appreciate it.

I work-around this problem for now by using KDE 4.6 activities which make it easy to close a set of application before hibernating and restoring them back to their old state after resuming. Anyway, my next notebook will have 8 GB of RAM and be 64-Bit, so this should not be much of the problem there. Just to hint at you that a fix is not urgent for me. But I will have that T42 where the problem happens at hand to test any workaround you provide.

Created attachment 56382 [details]
PM / Hibernate: Add new sysfs attribute for controlling reserved memory

The attached patch adds a new knob, /sys/power/reserved_size, allowing you to
set the size of memory (in bytes) to be reserved for device drivers'
hibernation callbacks while counting the number of memory pages to allocate.

Please check if you can set it to such a number that hibernation will always
succeed on your machine.

Sounds quite like extra pages allowance in TuxOnIce.

Okay, on 2.6.38.5-tp42-snapshot-resv-size-dirty with just your patch from this bug report I am starting with:

shambhala:/sys/power> ls
disk  image_size  pm_async  pm_test  reserved_size  resume  state  wakeup_count
shambhala:/sys/power> cat reserved_size 
1048576
shambhala:/sys/power> echo 2097152 > reserved_size
shambhala:/sys/power> cat reserved_size           
2097152

With that I suspended Amarok, KMail, Kontact, Akregaror on 4 activities with different backgrounds and whatnot just fine.

I bet I should remove any manual tweaking of image_size then, should I? I currently have:

echo 710000000 > /sys/power/image_size

Hmmm, I will remove it and reboot to get back the auto estimation.

Thanks.

The image size setting shouldn't matter and in fact I'd like to restore the
old autotuned value (2/5 of RAM), so it would be good if you could test this
one.

Do you need a patch for that?

Hmmm, I think I now have 2/5 of RAM as image_size autotune value with 2.6.38.5:

shambhala:/sys/power> free 
             total       used       free     shared    buffers     cached
Mem:       2073608    2018792      54816          0      34568     886860
-/+ buffers/cache:    1097364     976244
Swap:      4000180     141140    3859040
shambhala:/sys/power> cat image_size
844292096
shambhala:/sys/power> irb
irb(main):001:0> 2073608 * 1024
=> 2123374592
irb(main):002:0> 844292096 / 2123374592.0
=> 0.397618064745121
irb(main):003:0>

I removed the autotune refinement patch you asked me to test in bug #30482.

According to https://bugzilla.kernel.org/show_bug.cgi?id=30482#c5 that patch has been merged, but that doesn't seem to be the case!?

It has been merged into the mainline, but not necessarily into -stable.

Anyway, with the patch from bug #30482 removed, are you able to set
reserved_size to a number allowing you to successfully hibernate every
time?

Those 2 MB seem to do just fine with one KDE 4.6 session and lots of open stuff. Next week I hold a Linux training where I have a private and a job KDE session open and once. I will try whether the hibernation code takes that ;). If it doesn't - this sometimes didn't work with TuxOnIce either - even before Radeon KMS. Somewhere there might just be a limit?

I now had a hang a preallocation (unfortunately before I came around to compile with your patch from bug 30492). I raised reserved size to 4 MiB for now. Lets see how that goes. If it works, then I might go back to 2 MiB or even less in order to trigger bug 30492 with the patch from there compiled in.

This wasn't a hang I think, see there.

I tried to hibernate two running KDE 4 sessions with reserved_size upto 64 MiB:

shambhala:/sys/power> cat reserved_size 
67108864

Which failed with:

May  9 16:41:47 localhost kernel: PM: freeze of devices complete after 524.427 msecs
May  9 16:41:47 localhost kernel: PM: late freeze of devices complete after 0.509 msecs
May  9 16:41:47 localhost kernel: ACPI: Preparing to enter system sleep state S4
May  9 16:41:47 localhost kernel: PM: Saving platform NVS memory
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: PM: Creating hibernation image:
May  9 16:41:47 localhost kernel: PM: Need to copy 218459 pages
May  9 16:41:47 localhost kernel: PM: Normal pages needed: 113686 + 1024, available pages: 113492
May  9 16:41:47 localhost kernel: PM: Not enough free memory
May  9 16:41:47 localhost kernel: PM: Error -12 creating hibernation image
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: ACPI: Waking up from system sleep state S4
May  9 16:41:47 localhost kernel: PM: early recover of devices complete after 0.366 msecs

Does it make sense to go to even higher values? I am a bit puzzled, since for one KDE 4 session a value of 2 MiB has turned out to be enough for about 5-10 attempts - it didn't fail once.

Maybe here there is simply not enough memory available no matter what I reserve for driver allocation? If so, then so be it. That might be just a limit for a 2 GB RAM machine.

Is there a way to tell for sure whether reserved size is too low or there are general memory constraints? TuxOnIce logged how much of the reserved extra pages it used. Can in-kernel-hibernation do this too?

Ok, now it did it! First with 256 MiB reserved_size then also with 128 MiB reserved_size. Two KDE 4 sessions with compositing enabled. It had some problems to freeze tasks initially, cause an rdiff-backup and two KDE 4 desktop search indexers were running, but after some tries it did it. And if the rdiff-backup and those desktop searches fill the laptop harddisk with I/O requests up to its limit, thats just what to be expected. I am now testing 128 MiB and looks whether it works reliably. Still I wonder why 2 MiB was enough for one KDE 4 session, but two need something around 128 MiB.

It looks like the amount of memory the graphics driver allocates during
hibernation depends on how the GPU is loaded (the more 3D stuff you do before
hibernation, the more memory it needs to allocate).

So, I'd say reserved_size should match not only your hardware configuration,
but also your workload.

I'll try to post the patch from comment #3 for review, let's see if people
will like it. :-)

A patch referencing this bug report has been merged in v3.0-rc1:

commit ddeb648708108091a641adad0a438ec4fd8bf190
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun May 15 11:38:48 2011 +0200

    PM / Hibernate: Add sysfs knob to control size of memory for drivers