From: Bojan Smojver <bojan@rexursive.com>
To: Barry Song <21cnbao@gmail.com>
Cc: linux-pm@lists.linux-foundation.org,
LKML <linux-kernel@vger.kernel.org>,
DL-SHA-WorkGroupLinux <workgroup.linux@csr.com>
Subject: Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
Date: Thu, 29 Dec 2011 13:58:51 +1100 [thread overview]
Message-ID: <1325127531.2029.13.camel@shrek.rexursive.com> (raw)
In-Reply-To: <CAGsJ_4xH-9MXq8UJJFLW=upBqK+PXbWfDJhttBN=n2_M0PzMSw@mail.gmail.com>
On Thu, 2011-12-29 at 10:37 +0800, Barry Song wrote:
> i mean we can load image and decompress them in different threads when
> we reboot from hibernation. after i read codes more carefully, that
> has actually been done by lzo_decompress_threadfn().
Correct. Both hibernation and thaw are multi-threaded.
> here the problem is we didn't seem to get any faster after applying
> your compression patch when doing hibernation on SD/NAND.
> we are trying to figure out the reason.
This may depend on many factors:
- how much CPU power you have
- how many CPUs you have
- how much I/O can your disk do
Remember, there is one thread that does CRC32 as well and other threads
will have to sync with that thread.
Anyhow, it would be interesting to know where the bottleneck is on your
particular system. If you system has lots of CPU power and fast I/O, the
patch indeed may not do anything at all.
PS. I did my testing on a ThinkPad T510 laptop. It has a Core i5 M520
2.4 GHz mobile CPU (this appears to the system as 4 CPUs - it's two
physical cores with hyper-threading enabled). The disk is classic
platter based disk (Seagate ST9500420AS). There is 8 GB of RAM on this
system.
--
Bojan
WARNING: multiple messages have this Message-ID (diff)
From: Bojan Smojver <bojan@rexursive.com>
To: Barry Song <21cnbao@gmail.com>
Cc: rjw@sisk.pl, linux-pm@lists.linux-foundation.org,
LKML <linux-kernel@vger.kernel.org>,
DL-SHA-WorkGroupLinux <workgroup.linux@csr.com>
Subject: Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
Date: Thu, 29 Dec 2011 13:58:51 +1100 [thread overview]
Message-ID: <1325127531.2029.13.camel@shrek.rexursive.com> (raw)
In-Reply-To: <CAGsJ_4xH-9MXq8UJJFLW=upBqK+PXbWfDJhttBN=n2_M0PzMSw@mail.gmail.com>
On Thu, 2011-12-29 at 10:37 +0800, Barry Song wrote:
> i mean we can load image and decompress them in different threads when
> we reboot from hibernation. after i read codes more carefully, that
> has actually been done by lzo_decompress_threadfn().
Correct. Both hibernation and thaw are multi-threaded.
> here the problem is we didn't seem to get any faster after applying
> your compression patch when doing hibernation on SD/NAND.
> we are trying to figure out the reason.
This may depend on many factors:
- how much CPU power you have
- how many CPUs you have
- how much I/O can your disk do
Remember, there is one thread that does CRC32 as well and other threads
will have to sync with that thread.
Anyhow, it would be interesting to know where the bottleneck is on your
particular system. If you system has lots of CPU power and fast I/O, the
patch indeed may not do anything at all.
PS. I did my testing on a ThinkPad T510 laptop. It has a Core i5 M520
2.4 GHz mobile CPU (this appears to the system as 4 CPUs - it's two
physical cores with hyper-threading enabled). The disk is classic
platter based disk (Seagate ST9500420AS). There is 8 GB of RAM on this
system.
--
Bojan
next prev parent reply other threads:[~2011-12-29 2:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-27 12:27 [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image Barry Song
2011-12-27 12:27 ` Barry Song
2011-12-28 23:40 ` Bojan Smojver
2011-12-28 23:40 ` Bojan Smojver
2011-12-29 2:37 ` Barry Song
2011-12-29 2:37 ` Barry Song
2011-12-29 2:58 ` Bojan Smojver [this message]
2011-12-29 2:58 ` Bojan Smojver
2011-12-29 3:20 ` Barry Song
2011-12-29 3:20 ` Barry Song
2011-12-29 3:54 ` Bojan Smojver
2011-12-29 3:54 ` Bojan Smojver
2011-12-31 8:56 ` Barry Song
2011-12-31 8:56 ` Barry Song
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=1325127531.2029.13.camel@shrek.rexursive.com \
--to=bojan@rexursive.com \
--cc=21cnbao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=workgroup.linux@csr.com \
/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 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.