Re: [Suspend-devel] Resume performance
From: Anders Aagaard
Date: Fri Sep 05 2008 - 09:46:33 EST
Rafael J. Wysocki wrote:
On Friday, 5 of September 2008, Anders Aagaard wrote:
Hi
Hi,
This is a kernel problem, so let's CC the LKML.
I have a intel P35 board with a quad core cpu in it, it's currently
running as a server for a small network, and I'd like to be able to shut
it down when idle, and use wake on lan to wake it up when it's needed.
Now I got that part working quite well, but for some reason I have a
long delay in resume.
I seem to remember being able to resume this computer in 2-3 seconds
when I was testing it, now it needs 35 seconds to resume. It seems
regardless of resume options used, and it always resumes to a working
state without problems.
What kernel are you using at the moment and which one was used for the
testing?
I'm using gentoo's 2.6.25-r7, I've also tried vanilla sources.
I've tried quite a lot of things, booting with noapic/nosmp, booting a
kernel without usb/network drivers, disabling ahci (using ata_piix
driver instead of ahci), and there's always that one long delay. And
I'm not quite sure how the kernel printk timing information works, so
I'm not sure whats causing that delay.
Output from dmesg when booting with nosmp (to get accurate timing data):
scripts/show_delta -b "Force enabled HPET at resume"
[349.821150 < 7.039261 >] ata3.00: configured for UDMA/133
[349.821160 < 7.039271 >] sd 2:0:0:0: [sdc] 976773168 512-byte hardware
sectors (500108 MB)
[349.821165 < 7.039276 >] sd 2:0:0:0: [sdc] Write Protect is off
[349.821166 < 7.039277 >] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[349.821173 < 7.039284 >] sd 2:0:0:0: [sdc] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
[349.972801 < 7.190912 >] ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
[349.979060 < 7.197171 >] ata1.00: configured for UDMA/133
[349.979070 < 7.197181 >] sd 0:0:0:0: [sda] 976771055 512-byte hardware
sectors (500107 MB)
[349.979075 < 7.197186 >] sd 0:0:0:0: [sda] Write Protect is off
[349.979076 < 7.197187 >] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[349.979083 < 7.197194 >] sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
It looks like this happens here. Can you try to unload the network driver
before suspend, please?
I tried to build a kernel without it, and it still takes the exact same
amount to boot, I've also tried unloading usb drivers and it takes the
exact same amount of time.
[373.945179 < 31.163290 >] r8169: eth0: link up
[373.952159 < 31.170270 >] PM: Writing back config space on device
0000:02:02.0 at offset f (was 4020100, writing 4020104)
[373.952172 < 31.170283 >] PM: Writing back config space on device
0000:02:02.0 at offset 5 (was 0, writing fddf8000)
[373.952176 < 31.170287 >] PM: Writing back config space on device
0000:02:02.0 at offset 4 (was 0, writing fddfd000)
[373.952180 < 31.170291 >] PM: Writing back config space on device
0000:02:02.0 at offset 3 (was 0, writing 4410)
[373.952185 < 31.170296 >] PM: Writing back config space on device
0000:02:02.0 at offset 1 (was 2100000, writing 2100006)
Notice the long delay between all hd's found and it writing back config
space, note that this happens with or without that network card driver
in the kernel.
Attaching full log of boot + suspend/resume cycle, kernel booted with
nosmp/noapic, it takes the same amount of time without those options,
but timing data gets a bit garbled.
Thanks for your work so far, it's working quite well and saving me a lot
of power doing it this way, at this point I'm just trying to get it
faster :)
Sure, 35 seconds to resume is hardly acceptable.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/