All of lore.kernel.org
 help / color / mirror / Atom feed
* slow resume from suspend to disk
@ 2010-02-10 23:40 Mihai Donțu
  2010-02-11  0:11 ` Pedro Ribeiro
  2010-02-16 13:54 ` Pavel Machek
  0 siblings, 2 replies; 4+ messages in thread
From: Mihai Donțu @ 2010-02-10 23:40 UTC (permalink / raw)
  To: linux-kernel

Hi,

Is there any way to speed up the resume from suspend to disk? Currently, on my 
laptop it suspends in ~15s (wrote about 360MB) but resumes in ~120s and after 
that I'm still left with ~361MB in swap:

             total       used       free     shared    buffers     cached
Mem:       3333472    1139332    2194140          0      12808     473084
-/+ buffers/cache:     653440    2680032
Swap:      2104472     369428    1735044

Right now I'm better off with a cold boot.

Although I did not study the kernel code to see how things really work, I 
suspect on resume only necessary kernel data is loaded from swap and the 
userland tasks are left with the page fault mechanism to bring back their own 
data, which leads to an I/O storm on the swap device. Maybe changing the I/O 
scheduler from CFQ would help? or better yet, is there any way to tell the 
kernel to bring back all the pages from swap in one quick move? That would be 
something I want to put in my resume scripts.

$ uname -a
Linux mdontu-dell 2.6.32-gentoo-r3 #1 SMP PREEMPT Mon Feb 1 02:36:01 EET 2010 
x86_64 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux

I've installed Windows XP just for a test, started a few apps (like visual 
studio, mplayer, etc.) and then suspended/hibernated (~15s). It took roughly 
15s to come back.

Thanks,

PS: I'm editing this e-mail as I do tests and I just noticed that my /sbin 
directory is empty. rmmod is there and I needed it to reload the b43 driver 
which generally does not feel well after a suspend/resume. A reboot fixed it. 
Weird ...

-- 
Mihai Donțu

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: slow resume from suspend to disk
  2010-02-10 23:40 slow resume from suspend to disk Mihai Donțu
@ 2010-02-11  0:11 ` Pedro Ribeiro
  2010-02-15  9:54   ` Mihai Donțu
  2010-02-16 13:54 ` Pavel Machek
  1 sibling, 1 reply; 4+ messages in thread
From: Pedro Ribeiro @ 2010-02-11  0:11 UTC (permalink / raw)
  To: Mihai Donțu, linux-kernel

On 10 February 2010 23:40, Mihai Donțu <mihai.dontu@gmail.com> wrote:
> Hi,
>
> Is there any way to speed up the resume from suspend to disk? Currently, on my
> laptop it suspends in ~15s (wrote about 360MB) but resumes in ~120s and after
> that I'm still left with ~361MB in swap:
>
>             total       used       free     shared    buffers     cached
> Mem:       3333472    1139332    2194140          0      12808     473084
> -/+ buffers/cache:     653440    2680032
> Swap:      2104472     369428    1735044
>
> Right now I'm better off with a cold boot.
>
> Although I did not study the kernel code to see how things really work, I
> suspect on resume only necessary kernel data is loaded from swap and the
> userland tasks are left with the page fault mechanism to bring back their own
> data, which leads to an I/O storm on the swap device. Maybe changing the I/O
> scheduler from CFQ would help? or better yet, is there any way to tell the
> kernel to bring back all the pages from swap in one quick move? That would be
> something I want to put in my resume scripts.
>
> $ uname -a
> Linux mdontu-dell 2.6.32-gentoo-r3 #1 SMP PREEMPT Mon Feb 1 02:36:01 EET 2010
> x86_64 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux
>
> I've installed Windows XP just for a test, started a few apps (like visual
> studio, mplayer, etc.) and then suspended/hibernated (~15s). It took roughly
> 15s to come back.
>
> Thanks,
>
> PS: I'm editing this e-mail as I do tests and I just noticed that my /sbin
> directory is empty. rmmod is there and I needed it to reload the b43 driver
> which generally does not feel well after a suspend/resume. A reboot fixed it.
> Weird ...
>
> --
> Mihai Donțu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

If you know how to patch and compile a kernel, try http://www.tuxonice.net/
I find it way faster and more reliable than the in-kernel hibernation.

You also need to install at least the hibernate script, since it is
way better for hibernation that pm-utils which most distros use.

Ubuntu and some other distros have binary kernels already patched and
the hibernate script packaged.

Regards,
Pedro

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: slow resume from suspend to disk
  2010-02-11  0:11 ` Pedro Ribeiro
@ 2010-02-15  9:54   ` Mihai Donțu
  0 siblings, 0 replies; 4+ messages in thread
From: Mihai Donțu @ 2010-02-15  9:54 UTC (permalink / raw)
  To: Pedro Ribeiro; +Cc: linux-kernel

On Thursday 11 February 2010 02:11:00 Pedro Ribeiro wrote:
> On 10 February 2010 23:40, Mihai Donțu <mihai.dontu@gmail.com> wrote:
> > Hi,
> > 
> > Is there any way to speed up the resume from suspend to disk? Currently,
> > on my laptop it suspends in ~15s (wrote about 360MB) but resumes in
> > ~120s and after that I'm still left with ~361MB in swap:
> > 
> >             total       used       free     shared    buffers     cached
> > Mem:       3333472    1139332    2194140          0      12808     473084
> > -/+ buffers/cache:     653440    2680032
> > Swap:      2104472     369428    1735044
> > 
> > Right now I'm better off with a cold boot.
> > 
> > Although I did not study the kernel code to see how things really work, I
> > suspect on resume only necessary kernel data is loaded from swap and the
> > userland tasks are left with the page fault mechanism to bring back their
> > own data, which leads to an I/O storm on the swap device. Maybe changing
> > the I/O scheduler from CFQ would help? or better yet, is there any way
> > to tell the kernel to bring back all the pages from swap in one quick
> > move? That would be something I want to put in my resume scripts.
> > 
> > $ uname -a
> > Linux mdontu-dell 2.6.32-gentoo-r3 #1 SMP PREEMPT Mon Feb 1 02:36:01 EET
> > 2010 x86_64 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel
> > GNU/Linux
> > 
> > I've installed Windows XP just for a test, started a few apps (like
> > visual studio, mplayer, etc.) and then suspended/hibernated (~15s). It
> > took roughly 15s to come back.
> > 
> > Thanks,
> > 
> > PS: I'm editing this e-mail as I do tests and I just noticed that my
> > /sbin directory is empty. rmmod is there and I needed it to reload the
> > b43 driver which generally does not feel well after a suspend/resume. A
> > reboot fixed it. Weird ...
> 
> If you know how to patch and compile a kernel, try http://www.tuxonice.net/
> I find it way faster and more reliable than the in-kernel hibernation.

Luckily, Gentoo has en ebuild for this. ;)

> You also need to install at least the hibernate script, since it is
> way better for hibernation that pm-utils which most distros use.
> 
> Ubuntu and some other distros have binary kernels already patched and
> the hibernate script packaged.

I have tested tuxonice for the past three days. It turns out it's the real 
deal when it comes to suspend to disk and the devices "feel" better after the 
tuxonice resume than after the built-in swsusp. Mm.

Thanks,

-- 
Mihai Donțu

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: slow resume from suspend to disk
  2010-02-10 23:40 slow resume from suspend to disk Mihai Donțu
  2010-02-11  0:11 ` Pedro Ribeiro
@ 2010-02-16 13:54 ` Pavel Machek
  1 sibling, 0 replies; 4+ messages in thread
From: Pavel Machek @ 2010-02-16 13:54 UTC (permalink / raw)
  To: Mihai Don??u, Rafael J. Wysocki, Linux-pm mailing list; +Cc: linux-kernel

Hi!
> 
> Is there any way to speed up the resume from suspend to disk? Currently, on my 
> laptop it suspends in ~15s (wrote about 360MB) but resumes in ~120s and after 
> that I'm still left with ~361MB in swap:
> 
>              total       used       free     shared    buffers     cached
> Mem:       3333472    1139332    2194140          0      12808     473084
> -/+ buffers/cache:     653440    2680032
> Swap:      2104472     369428    1735044
> 
> Right now I'm better off with a cold boot.

That's way too slow. Are you using in-kernel swsusp, or userland
s2disk? dmesgM
> 
> Although I did not study the kernel code to see how things really work, I 
> suspect on resume only necessary kernel data is loaded from swap and the 
> userland tasks are left with the page fault mechanism to bring back their own 
> data, which leads to an I/O storm on the swap device. Maybe changing the I/O 
> scheduler from CFQ would help? or better yet, is there any way to tell the 
> kernel to bring back all the pages from swap in one quick move? That would be 
> something I want to put in my resume scripts.
> 
> $ uname -a
> Linux mdontu-dell 2.6.32-gentoo-r3 #1 SMP PREEMPT Mon Feb 1 02:36:01 EET 2010 
> x86_64 Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz GenuineIntel GNU/Linux
> 
> I've installed Windows XP just for a test, started a few apps (like visual 
> studio, mplayer, etc.) and then suspended/hibernated (~15s). It took roughly 
> 15s to come back.
> 
> Thanks,
> 
> PS: I'm editing this e-mail as I do tests and I just noticed that my /sbin 
> directory is empty. rmmod is there and I needed it to reload the b43 driver 
> which generally does not feel well after a suspend/resume. A reboot fixed it. 
> Weird ...
> 

Seems like your system has problems...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-02-16 13:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-10 23:40 slow resume from suspend to disk Mihai Donțu
2010-02-11  0:11 ` Pedro Ribeiro
2010-02-15  9:54   ` Mihai Donțu
2010-02-16 13:54 ` Pavel Machek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.