Bug 116313

Did you estimate the mbyte/sec bandwidth during the "freeing memory" phase? 
Otherwise how can you say a bit slow if you don't know the write bandwidth? 
 
If you get 10mbyte/sec and your harddisk bandwidth measured by hdparm -t is 
11mbytes/sec, the only way to make it faster is to change the hardware (it'll 
seek a bit). 
 
the write bandwidth must be close to the hdparm -t value, that's all, it 
doesn't matter how wall clock time it takes. 
 
 

Hello,   
   
I also have serious swsusp performance problems. Restoring from disk takes   
about 50-60 seconds(!), swapping out takes up to 40. most of the time is spent   
in freeing memory, and (I think) resetting PCI devices. Also, I get constant  
errors about failing to enable/disable "psmouse.c" (is this about a PS/2  
mouse? I don't have one).  
 
Freeing memory takes about 10 seconds here, writing RAM to swap about another 
10. (1GB RAM) 
 
Jens  

Andrea, "it feels slow". I know this is not exact, but i have done quite some
suspends in the last years and the hardware is a new machine, hdparm tells me it
is reading 26MB/second and writing 256MB to /tmp with dd takes 16 seconds
(including sync) on ext3.

This is why i asked for a swap benchmark tool :-)

what i have done now is:
strolchi:~ # cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/hda3                               partition       1044216 260688  -2
strolchi:~ # free
             total       used       free     shared    buffers     cached
Mem:        506956     206672     300284          0        780      30332
-/+ buffers/cache:     175560     331396
Swap:      1044216     260688     783528
strolchi:~ # time swapoff -a

real    0m22.880s
user    0m0.000s
sys     0m12.509s

and while swapoff -a was running, gkrellm (a system monitor) showed around
10MB/seconds read from the disk, which seems to match the numbers, but i am not
sure if this is a valid test case.

just to keep this bug on topic:

(In reply to comment #2)

> most of the time is spent   
> [...] and (I think) resetting PCI devices. Also, I get constant  
> errors about failing to enable/disable "psmouse.c" (is this about a PS/2  
> mouse? I don't have one).  

this is unrelated to this bug, this bug is only about swapping performance.

> Freeing memory takes about 10 seconds here, writing RAM to swap about another 
> 10. (1GB RAM) 

ok, we'd need to know how many pages are actually freed and how many are written
(this is shown during suspend) and how fast your disk is ("hdparm -tT /dev/hda"
output).

Hi, 
 
I attached a screenshot of the suspend process (I know this is a bit lame ;), 
but I don't know how much other info you need and I don't know how this can be 
copied to a file when the system is about to shut down). 
 
Here's what I saw: 
214205 pages freed, 25760 pages copied, pagedir: 101 pages 
 

Created attachment 49549 [details]
screenshot of suspend process

> 214205 pages freed, 25760 pages copied, pagedir: 101 pages  
 
I don't know much on software suspend, but my guess is that most of the time is spent 
writing back dirty pages to the filesystem intead of swapping out.  Try running sync 
before the suspend and see if it is any faster. 
 
 

Regarding sync, we do it in userspace before activating swsusp and in kernel;
excerpt from kernel/power/disk.c:

static int prepare_processes(void)
{
    int error;
    pm_prepare_console();
    sys_sync();                 // <------ look here :-)
    disable_nonboot_cpus();
    if (freeze_processes()) {
        error = -EBUSY;
        goto thaw;
    }
    if (pm_disk_mode == PM_DISK_PLATFORM) {
        if (pm_ops && pm_ops->prepare) {
            if ((error = pm_ops->prepare(PM_SUSPEND_DISK)))
                goto thaw;
        }
    }
    /* Free memory before shutting down devices. */
    free_some_memory();
    return 0;
thaw:
    thaw_processes();
    enable_nonboot_cpus();
    pm_restore_console();
    return error;
}

Here's a timetable (rough) for resume: (total resume time: 40 seconds)  
 
-7    BIOS screen vanishes, SuSE boot logo appears 
0      screen blank after loading kernel  
12     restoring pages at 100%, screen blanks 
       pause 
22     hdd starts thrashing  
40     KDE desktop appears (slowly, as if swapped in from disk) 
47     password prompt appears, system is useable again 
 
IMHO, this is far too long. But I don't know what can be optimized. 
 
Jens 

I think swapping in user space is mostly seeks. It might help to have
suspend write all pages from the current working set to swap in one go,
followed by the dirty-but-not-recently-accessed pages. On resume, we
read the entire working set in one pass before resuming user space
processes.

Just my 2c

yes, probably free_some_memory() should just do that - free _some_, not all and
check if it is enough. If yes => continue, if no => try again.
But this does not explain why it feels slower than in the past. we always had
this free_some_memory there.

Olaf, yes, avoiding seeks is possible and helps, but it is not something we want
to do in -rc stage.

Minute to resume seems pretty much okay to me, sorry. You can try suspend2.net
patches, but thats not something we want/can do for suse10.

OTOH it should not be slower than 9.3 / vanilla. If it is, something is wrong
somewhere...

*grin* I agree completely. 

Hello, 
 
I don't know if this helps, just FYI: 
suspend to disk and resuming from disk is *dreadfully* slow when VMware 5.0 is 
running with a Win2k guest active. I'm talking about five to ten minutes 
writing pages to disk during suspend and just as long resuming. 
 
This on a AMD 2600+XP machine, 1G RAM, Asus A7n8X Deluxe with nForec2 chipset. 
 
During resume, the screen shows a distorted version of the text framebuffer 
("half" started X?) for a long time (also several minutes), and the harddisk 
is _not_ constantly active, only every couple seconds. 
 
It's probably VMware's fault :-) and I know that you don't debug binary (or 
half binary) modules but maybe this helps you anyway. 
 
Thanks, 
 
Jens 

Because the LATER and REMIND resolutions have been removed, the resolution of this bug has changed from LATER to WONTFIX. If this bug needs to be reconsidered, reopen it and set a future "Target Milestone for Fix."