From: Nigel Cunningham <nigel@tuxonice.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-pm@lists.linux-foundation.org,
tuxonice-devel@lists.tuxonice.net, linux-kernel@vger.kernel.org,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [TuxOnIce-devel] [RFC] TuxOnIce
Date: Wed, 27 May 2009 10:06:03 +1000 [thread overview]
Message-ID: <1243382763.13930.112.camel@nigel-laptop> (raw)
In-Reply-To: <200905270037.43991.rjw@sisk.pl>
Hi.
On Wed, 2009-05-27 at 00:37 +0200, Rafael J. Wysocki wrote:
> Well, first, our multithreaded I/O is probably not the same thing as you think
> of, because we have an option to use multiple user space threads that process
> image data (compress, encrypt and feed them to the kernel).
Well, I'm using multiple kernel threads, so it's probably not that
different, but okay.
> Now, we found that it only improves performance substantially if both
> compression and encryption are used.
>
> As far as the numbers are concerned, I don't have the raw hdparm numbers
> handy, but image writing speed with compression alone usually is in the
> 60 MB/s - 100 MB/s range, sometimes more than 100 MB/s, but that really depends
> on the system. If encryption is added, it drops substantially and multiple
> threads allow us to restore the previous performance (not 100%, but close
> enough to be worth the additional complexity IMO).
Okay. That's still a significant improvement over 20 or 30 MB/s. It
depends, of course, also on the compression ratio that's achieved.
> Still, one should always take the total length of hibernate-resume cycle into
> accout and the image writing/reading time need not be the greatest part of it.
Yes, the total time is what matters. I'm focussing on the I/O speed
because - especially with larger images - it tends to be the biggest
portion.
Regards,
Nigel
next prev parent reply other threads:[~2009-05-27 0:04 UTC|newest]
Thread overview: 141+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-06 14:38 [RFC] TuxOnIce Nigel Cunningham
2009-05-06 14:38 ` [PATCH 1/19] TuxOnIce: Documentation Nigel Cunningham
2009-05-16 20:10 ` Vegard Nossum
2009-05-16 22:18 ` Nigel Cunningham
2009-05-06 14:38 ` [PATCH 2/19] TuxOnIce: GEMS support Nigel Cunningham
2009-05-06 14:38 ` [PATCH 3/19] TuxOnIce: Make drop_pagecache non-static and declared in mm.h Nigel Cunningham
2009-05-06 14:39 ` [PATCH 4/19] TuxOnIce: Add support for just thawing kernel threads Nigel Cunningham
2009-05-06 14:39 ` [PATCH 5/19] TuxOnIce: Create means of determining how many pages can be allocated Nigel Cunningham
2009-05-06 14:39 ` [PATCH 6/19] TuxOnIce: Make functions and variables shared with swsusp non-static Nigel Cunningham
2009-05-06 14:39 ` [PATCH 7/19] TuxOnIce: Modify swsusp bitmaps to allow modification during scanning Nigel Cunningham
2009-05-06 14:39 ` [PATCH 8/19] TuxOnIce: Add core TuxOnIce code Nigel Cunningham
2009-05-06 14:39 ` [PATCH 9/19] TuxOnIce: Netlink support Nigel Cunningham
2009-05-06 21:03 ` Sam Ravnborg
2009-05-06 21:35 ` Nigel Cunningham
2009-05-07 4:34 ` Sam Ravnborg
2009-05-06 14:39 ` [PATCH 10/19] TuxOnIce: Storage manager support Nigel Cunningham
2009-05-06 14:39 ` [PATCH 11/19] TuxOnIce: Block I/O engine Nigel Cunningham
2009-05-06 14:39 ` [PATCH 12/19] TuxOnIce: Compression support Nigel Cunningham
2009-05-06 14:39 ` [PATCH 13/19] TuxOnIce: File allocator Nigel Cunningham
2009-05-06 14:39 ` [PATCH 14/19] TuxOnIce: Swap support Nigel Cunningham
2009-05-06 14:39 ` [PATCH 15/19] TuxOnIce: Userspace user interface support Nigel Cunningham
2009-05-06 14:39 ` [PATCH 16/19] TuxOnIce: Warn user if an initrd doesn't include an attempt at resuming Nigel Cunningham
2009-05-06 14:39 ` [PATCH 17/19] TuxOnIce: Support for replacing swsusp Nigel Cunningham
2009-05-06 14:39 ` [PATCH 18/19] TuxOnIce: Provide a means of determining the freezer state Nigel Cunningham
2009-05-06 14:39 ` [PATCH 19/19] TuxOnIce: Don't try to wake kswapd if the freezer is on Nigel Cunningham
2009-05-07 12:09 ` [RFC] TuxOnIce Pavel Machek
2009-05-07 15:28 ` [TuxOnIce-devel] " Kenneth Crudup
2009-05-07 17:05 ` Kenneth Crudup
2009-05-09 9:10 ` Stefan Richter
2009-05-10 5:37 ` Pavel Machek
2009-05-10 5:37 ` Pavel Machek
2009-05-07 16:55 ` U Kuehn
2009-05-07 17:45 ` Rafael J. Wysocki
2009-05-07 17:49 ` Kenneth Crudup
2009-05-07 18:54 ` Fabio Comolli
2009-05-07 18:57 ` Kenneth Crudup
2009-05-07 17:52 ` Matt Price
2009-05-07 18:22 ` Rafael J. Wysocki
2009-05-07 18:57 ` Fabio Comolli
2009-05-07 19:27 ` Rafael J. Wysocki
2009-05-07 20:41 ` Nigel Cunningham
2009-05-07 23:14 ` Jesse Barnes
2009-05-07 23:32 ` Nigel Cunningham
2009-05-07 23:43 ` Jesse Barnes
2009-05-08 0:13 ` Nigel Cunningham
2009-05-08 0:39 ` Jesse Barnes
2009-05-08 0:49 ` Nigel Cunningham
2009-05-08 0:18 ` Rafael J. Wysocki
2009-05-07 21:46 ` Pavel Machek
2009-05-08 7:11 ` Fabio Comolli
2009-05-07 21:42 ` Pavel Machek
2009-05-08 0:11 ` Alex Goebel
2009-05-07 17:42 ` Rafael J. Wysocki
2009-05-07 20:37 ` Nigel Cunningham
2009-05-07 21:51 ` Pavel Machek
2009-05-08 1:34 ` [TuxOnIce-devel] " Nigel Cunningham
2009-05-08 14:11 ` Rafael J. Wysocki
2009-05-08 21:52 ` Nigel Cunningham
2009-05-08 22:46 ` Rafael J. Wysocki
2009-05-08 23:30 ` Nigel Cunningham
2009-05-08 23:43 ` Rafael J. Wysocki
2009-05-25 10:05 ` Nigel Cunningham
2009-05-25 12:43 ` Pavel Machek
2009-05-25 13:15 ` Nigel Cunningham
2009-05-25 21:43 ` Rafael J. Wysocki
[not found] ` <1243288705.16743.129.camel@nigel-laptop>
2009-05-25 22:39 ` Rafael J. Wysocki
2009-05-26 0:39 ` Nigel Cunningham
2009-05-26 22:27 ` Rafael J. Wysocki
2009-05-27 0:02 ` Nigel Cunningham
2009-05-27 18:26 ` [linux-pm] " Len Brown
2009-05-25 22:45 ` Oliver Neukum
2009-05-25 22:58 ` Rafael J. Wysocki
2009-05-25 23:13 ` Oliver Neukum
2009-05-27 14:38 ` Martin Steigerwald
2009-05-26 0:42 ` Nigel Cunningham
2009-05-26 9:19 ` Pavel Machek
2009-05-26 11:07 ` Oliver Neukum
2009-05-26 21:33 ` Nigel Cunningham
2009-05-26 21:56 ` [linux-pm] " Alan Stern
2009-05-26 22:24 ` Oliver Neukum
2009-05-27 0:00 ` Nigel Cunningham
2009-05-26 23:59 ` Nigel Cunningham
2009-05-26 21:36 ` Pavel Machek
2009-05-26 21:29 ` Nigel Cunningham
2009-05-26 22:51 ` Oliver Neukum
2009-05-26 23:10 ` Rafael J. Wysocki
2009-05-26 0:42 ` Nigel Cunningham
2009-05-08 23:44 ` Ray Lee
2009-05-27 19:10 ` Len Brown
2009-05-27 23:43 ` Nigel Cunningham
2009-05-09 13:54 ` Pavel Machek
2009-05-25 9:53 ` Nigel Cunningham
2009-05-25 22:02 ` Rafael J. Wysocki
2009-05-26 0:19 ` Nigel Cunningham
2009-05-26 22:37 ` Rafael J. Wysocki
2009-05-27 0:06 ` Nigel Cunningham [this message]
2009-05-28 11:50 ` Pavel Machek
2009-05-09 13:27 ` Pavel Machek
2009-05-09 19:32 ` Rafael J. Wysocki
2009-05-09 22:22 ` Nigel Cunningham
2009-05-14 9:16 ` Pavel Machek
2009-05-16 23:11 ` Nigel Cunningham
2009-05-09 13:03 ` Pavel Machek
2009-05-08 19:44 ` Bartlomiej Zolnierkiewicz
2009-05-08 21:03 ` Rafael J. Wysocki
2009-05-08 22:37 ` Nigel Cunningham
2009-05-08 21:59 ` Nigel Cunningham
2009-05-08 23:05 ` Bartlomiej Zolnierkiewicz
2009-05-08 23:15 ` Nigel Cunningham
2009-05-09 13:58 ` Pavel Machek
2009-05-25 9:27 ` Nigel Cunningham
2009-05-25 12:32 ` Pavel Machek
2009-05-25 13:22 ` Oliver Neukum
2009-05-25 13:26 ` Pavel Machek
2009-05-25 21:50 ` Nigel Cunningham
2009-05-25 21:39 ` Nigel Cunningham
2009-05-25 22:29 ` Oliver Neukum
2009-05-26 0:28 ` Nigel Cunningham
2009-05-26 0:35 ` david
2009-05-26 0:47 ` Nigel Cunningham
2009-05-26 8:43 ` Pavel Machek
2009-05-26 10:56 ` Oliver Neukum
2009-05-09 11:12 ` Pekka Enberg
2009-05-07 22:37 ` trekker.dk
2009-05-08 1:17 ` Shannon McMackin
2009-05-08 21:47 ` Fabio Comolli
2009-05-10 5:38 ` Pavel Machek
2009-05-11 20:10 ` Vladislav Bolkhovitin
2009-05-10 5:38 ` Pavel Machek
2009-05-11 21:19 ` trekker.dk
2009-05-11 21:23 ` Pavel Machek
2009-05-13 20:19 ` trekker.dk
2009-05-13 20:24 ` Pavel Machek
2009-05-13 22:07 ` trekker.dk
2009-05-11 23:23 ` Alex Goebel
2009-05-16 19:07 ` Martin Steigerwald
2009-05-17 2:53 ` Matt Price
2009-05-17 3:06 ` Nigel Cunningham
2009-05-17 3:24 ` Matt Price
2009-05-17 3:57 ` Benjamin Herrenschmidt
2009-05-17 5:02 ` Nigel Cunningham
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=1243382763.13930.112.camel@nigel-laptop \
--to=nigel@tuxonice.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=tuxonice-devel@lists.tuxonice.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;
as well as URLs for NNTP newsgroup(s).