Bug 8943 - After wakeup from suspend to disk, machine loops in memory clean up
Summary: After wakeup from suspend to disk, machine loops in memory clean up
Status: REJECTED INVALID
Alias: None
Product: Memory Management
Classification: Unclassified
Component: Page Allocator (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2007-08-27 00:54 UTC by Stephan Buehne
Modified: 2007-08-27 13:45 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.22.4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Stephan Buehne 2007-08-27 00:54:05 UTC
Most recent kernel where this bug did not occur: 2.6.21.5 (latest version used before)
Distribution:
Hardware Environment: 1GB RAM, Intel Pentium M ICH6
Software Environment: Kernel 2.6.22.4, KDE 3.5.7. ATI display driver version 8.40.4-x86.x86_64
Problem Description:
Use "Suspend to disk" feature. After resuming from this, the machine loops in memory management, by trying to clean up the memory. By monitoring the memory usage you can see that the kernel tries to clean up the whole memory. The memory usage stays below 100MB, whereas more then 500MB was in use before supsend.
Therefore the machine becomes unusable because of extensivly page in/page out activity and must be rebooted.

Steps to reproduce: Run "Suspend to disk" several times. After resuming the problem occurs.
Comment 1 Andrew Morton 2007-08-27 01:00:14 UTC
I'm not sure that I understand this very well.  Can you tell us more
about how you're monitoring the memory usage, and what resutls you are
seeing and what behaviour you're observing?
Comment 2 Stephan Buehne 2007-08-27 01:22:49 UTC
Observed behaviour:
- It takes very long,until the original screen is restored, after the suspend image was read
- The disk is always heavily busy
- The machine responds very slowly to any action, e.g. starting new programs, switching to a running program or a different desktop
- The memory usage is display by the tool "xosview", which show the actual used memory. Under norma circumstances, approx. 25% - 40% of the memory (of 1 GB) is used for  programs and the remaining part is used for file system caching. The overall memory usage is therefore near to 1GB, without making usage of the swap disk at all.  When the problem occurs, not more than 80 - 90 MB of memory ("used + shared memory") is in use and the memory usage is not increasing anymore. So it looks as if the machine tries to run all programs in 100 MB of memory only. The memory ("used + shared memory") is always between 50MB and 80 MB. So once increased to 80 MB, the machine swaps out the memory immediately once again.
Comment 3 Rafael J. Wysocki 2007-08-27 03:41:10 UTC
Can you please try without the ATI driver?
Comment 4 Stephan Buehne 2007-08-27 13:20:54 UTC
Checked without ati display driver and also with different versions of the ati driver.
The problem is not reproducible using the "radeon" display driver or versions of the ati driver >= 8.38.6
Using versions 8.39.4 or 8.40.4 the observed problem reappears.
As workarround I will use now the 8.38.6 version of the ati driver.

Thank's for your help
Comment 5 Andrew Morton 2007-08-27 13:45:43 UTC
OK, thanks, I'll close the report as it appears to be a memory leak in
ATI's driver.

Note You need to log in before you can comment on or make changes to this bug.