public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anders Aagaard <aagaande@gmail.com>
To: suspend-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Suspend-devel] Resume performance
Date: Tue, 09 Sep 2008 22:09:42 +0200	[thread overview]
Message-ID: <48C6D806.7020506@gmail.com> (raw)
In-Reply-To: <200809091613.44959.rjw@sisk.pl>

Rafael J. Wysocki wrote:
> On Sunday, 7 of September 2008, Anders Aagaard wrote:
>> 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?
> 
> Well, it should be a bit less than that.  Usually, the resume shouldn't take
> more than 5 sec.
> 
>> 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).
> 
> That may matter a lot.  It would be interesting to check if detaching any of
> those devices from the first machine helps. ;-)
> 
>>   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.
> 
> Of course the USB devices are also resumed and that takes time (comparable
> to the boot time).

Pulling out all my usb devices takes the resume time to 30.4

> 
> Thanks,
> Rafael
> 


  reply	other threads:[~2008-09-09 20:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <48C10908.60101@gmail.com>
2008-09-05 11:08 ` [Suspend-devel] Resume performance Rafael J. Wysocki
2008-09-05 13:46   ` Anders Aagaard
2008-09-05 18:43     ` Rafael J. Wysocki
2008-09-07 10:35       ` Anders Aagaard
2008-09-09 14:13         ` Rafael J. Wysocki
2008-09-09 20:09           ` Anders Aagaard [this message]
2008-09-09 20:31             ` Rafael J. Wysocki
2008-09-09 20:31               ` Anders Aagaard
2008-09-11  8:53               ` Anders Aagaard
2008-09-12 12:23         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C6D806.7020506@gmail.com \
    --to=aagaande@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suspend-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox