Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Barry Song]

> Use threads for LZO compression/decompression on hibernate/thaw.
> Improve buffering on hibernate/thaw.
> Calculate/verify CRC32 of the image pages on hibernate/thaw.

> In my testing, this improved write/read speed by a factor of about two.

> Signed-off-by: Bojan Smojver <bojan@rexursive.com>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

hi Bojan,
this patch is definitely great!
any plan to write the same patch for decompress and restore? i think
that is probably more important than compression and hibernation to
improve bootup speed.

Thanks
barry

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Bojan Smojver]

On Tue, 2011-12-27 at 20:27 +0800, Barry Song wrote:
> this patch is definitely great!

Thanks, I'm glad you liked it.

> any plan to write the same patch for decompress and restore? i think
> that is probably more important than compression and hibernation to
> improve bootup speed.

I'm not sure I understand what you mean here. Can you elaborate?

-- 
Bojan

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Barry Song]

2011/12/29 Bojan Smojver <bojan@rexursive.com>:
> On Tue, 2011-12-27 at 20:27 +0800, Barry Song wrote:
>> this patch is definitely great!
>
> Thanks, I'm glad you liked it.
>
>> any plan to write the same patch for decompress and restore? i think
>> that is probably more important than compression and hibernation to
>> improve bootup speed.
>
> I'm not sure I understand what you mean here. Can you elaborate?

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().

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.

>
> --
> Bojan
>

-barry

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Bojan Smojver]

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

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Barry Song]

2011/12/29 Bojan Smojver <bojan@rexursive.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.

well. our guys are still debugging.
the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
to a SD card or NAND.
a phenomenon we saw is that multi-BIOs is not merged into a request by
block level elevator. so the SD/NANDdisk driver handles many small
request one page by one page.

>
> --
> Bojan
>
-barry

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Bojan Smojver]

On Thu, 2011-12-29 at 11:20 +0800, Barry Song wrote:
> the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
> to a SD card or NAND.
> a phenomenon we saw is that multi-BIOs is not merged into a request by
> block level elevator. so the SD/NANDdisk driver handles many small
> request one page by one page. 

Interesting, thanks.

-- 
Bojan

Re: [PATCH] PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image

[Barry Song]

2011/12/29 Bojan Smojver <bojan@rexursive.com>:
> On Thu, 2011-12-29 at 11:20 +0800, Barry Song wrote:
>> the platform is ARM cortex-a9 single-core 1Ghz SoC and we save image
>> to a SD card or NAND.
>> a phenomenon we saw is that multi-BIOs is not merged into a request by
>> block level elevator. so the SD/NANDdisk driver handles many small
>> request one page by one page.
>
> Interesting, thanks.

we did see some visible IO performance improvement now. the main
reason we didn't see that before is because we enable on-demand
cpufreq in default status. while saving and resuming from snapshot,
cpu frequence is switched frequently due to IO sleep and
compression/uncompression CPU consume. then we enable Performance
policy while booting, and move to on-demand after system boot, we did
see a great performance improvement.
for our inand card, the speed to read/uncompress snapshot is improved
from 7.x MB to 11MB.

>
> --
> Bojan
>
-barry