Re: [Suspend-devel] Resume performance

From: Anders Aagaard
Date: Sun Sep 07 2008 - 06:35:49 EST


Rafael J. Wysocki wrote:
On Friday, 5 of September 2008, Anders Aagaard wrote:
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.

Would it be possible to test 2.6.27-rc5-gi7 from kernel.org?

Tested, makes no difference.


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.

Can you try to boot with init=/bin/bash and suspend to RAM? (Please have a
look at section 2 of Documentation/power/basic-pm-debugging.txt in the newer
kernel sources).

I checked without X before, but forgot to unload the nvidia module, that apparently makes a big difference, I did some numbers with scripts/show_delta -b "Back to C".

Nvidia and X : 32 seconds
No X (same result as booting with init=/bin/bash) : 8.3 seconds
Git kernel : 8.2 seconds
Light kernel (no sound, network card and usb drivers) : 8.17 seconds
ATI card instead of nvidia : 8.22 seconds

I think we found the problem, I already replaced nvidia hardware in one computer to resolve another issue. Really appreciate your help on this issue, this resume time works pretty well for me, it was a bit ridiculous when I could boot faster than resume.

Is 8 seconds fairly expected? My other computer (same ati card) boots in about 2 seconds, but there's a lot less hardware in it (6 hd's and a ton of usb devices in one computer, 1 hd and 1 usb device in the other). I checked cold booting with and without usb devices, my light kernel boots to /bin/bash in 2.5 seconds, normal kernel about 7-8. But I dont see anything about usb on resume.

Thanks a lot, Anders



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/