lkml.org 
[lkml]   [2008]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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
    >



    \
     
     \ /
      Last update: 2008-09-05 15:49    [W:3.396 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site