Very slow suspend-to-ram, poor VM allocation

Bug #367520 reported by Chris on 2009-04-26
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

Bug Description

I seem to be affected by a bug similar to (or the same as) #79599 and #290184. I'm reporting this separately because those two bugs have been marked as "Rejected" and "Invalid", in one case with the observation that the bug policy requires a new bug to be filed when the original reporter is no longer seeing the problem. Also, I think I may have a lead on what is causing this issue.

My system: Acer Aspire 5100 laptop, 2 GB RAM, Intrepid amd64, kernel 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009, ATI fglrx driver is the only proprietary module, running Gnome and Metacity with compositing enabled.

When I boot the system it is pretty fast. I can launch lots of programs and they don't take up the full 2 GB of memory, so a good fraction of it is used as cache and the swap space is empty.

After a suspend-to-ram and resume, only the first 1 GB of RAM is in use, and the swap is heavily used (about 800 MB is typical). I think this swapping is what accounts for the slowness and he heavy disk activity people are seeing.

In my case, the resume time can vary from about 5 seconds to >15 minutes (I cold-booted that time rather than keep waiting).

At a guess, it looks as if the suspend code thinks the suspended RAM can't exceed 1 GB. So when the system suspends, it swaps out everything above 1 GB. Resume is then very slow because critical parts of the OS need to get pulled back in from swap, and the system runs slowly after resume for the same reason. Strangely, the usage of real RAM tends to stay below 1 GB even after the machine has been running post-resume, so performance doesn't recover very well.

It may be relevant that my system was installed with only 1 GB of RAM in it, and upgraded to 2 GB after the install.

UPDATE: Switching from the fglrx to the open-source ati video driver seems to have cured the problem. On my laptop it was necessary to tweak the file

/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-acer.fdi

to add some more quirks to avoid having the screen go crazy after resume. The updated entry looks like this:

        <match key="system.hardware.product" contains_outof="1520;1650;5100;5110;5570;5920">
          <merge key="power_management.quirk.radeon_off" type="bool">true</merge>
          <merge key="power_management.quirk.vbe_post" type="bool">true</merge>
          <merge key="power_management.quirk.vbemode_restore" type="bool">true</merge>
          <merge key="power_management.quirk.vbestate_restore" type="bool">true</merge>
        </match>

Chris (bridgeriver) on 2009-05-05
description: updated

This bug was reported a while ago and there hasn't been any activity in
it recently. We were wondering if this is still an issue? Can you try
with the latest Karmic 9.10 release of Ubuntu? ISO CD images are
available from http://cdimage.ubuntu.com/releases/ .

If the issue remains, could you run the following command from a
Terminal (Applications->Accessories->Terminal) while running Karmic. It
will automatically gather and attach updated debug information to this
report.

apport-collect -p linux 367520

Thanks in advance

Changed in linux (Ubuntu):
status: New → Incomplete

Hi Pepe,

  I haven't been experimenting with that machine lately because an electrostatic discharge seems to have wrecked its USB subsystem, making it impossible for me to boot Karmic off a pen drive. I don't want to upgrade the OS to Karmic because of this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/318325?comments=all

  If that one gets fixed and I find a way to get USB working again I'll be more motivated to invest time. But there are other people with other, non-broken hardware who seem to be experiencing the same problem. I think I saw an explanation of it somewhere, to the effect that not all of RAM is reloaded from disk on wakeup from hibernation. TuxOnIce might be the solution, but I haven't tried it and am not sure.

  Sorry not to be more helpful (and to have a broken laptop).

  Chris

----- Original Message ----
From: ^_Pepe_^ <email address hidden>
To: <email address hidden>
Sent: Wed, January 20, 2010 4:01:38 AM
Subject: [Bug 367520] Re: Very slow suspend-to-ram, poor VM allocation

This bug was reported a while ago and there hasn't been any activity in
it recently. We were wondering if this is still an issue? Can you try
with the latest Karmic 9.10 release of Ubuntu? ISO CD images are
available from http://cdimage.ubuntu.com/releases/ .

If the issue remains, could you run the following command from a
Terminal (Applications->Accessories->Terminal) while running Karmic. It
will automatically gather and attach updated debug information to this
report.

apport-collect -p linux 367520

Thanks in advance

** Changed in: linux (Ubuntu)
       Status: New => Incomplete

--
Very slow suspend-to-ram, poor VM allocation
https://bugs.launchpad.net/bugs/367520
You received this bug notification because you are a direct subscriber
of the bug.

Chris,

Thanks for your comments and your help.

I'm going to mark this bug as closed, since you don't have the opportunity to test this hardware nomore.

I'm sorry about your computer

Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers