linux-kernel - Re: [Suspend-devel] Resume performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48C13827.1010409@gmail.com>
Date:	Fri, 05 Sep 2008 15:46:15 +0200
From:	Anders Aagaard <aagaande@...il.com>
To:	linux-kernel@...r.kernel.org
CC:	suspend-devel@...ts.sourceforge.net
Subject: Re: [Suspend-devel] Resume performance

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/