The following two patches add suspend/resume benchmarking.
The first is the more important one. During suspend, it times the image
writeout + fsync(), and stores the result in the swsusp header. During
resume, it times image load, then prints writeout, readin, and total
timings and speeds.
The second is an optional two-liner that simplifies repeated benchmarks
by making suspend reboot rather than power off, and pausing resume after
the statistics are printed.
Using these, I did a bunch of timings. All the times were done with
"image size" limited to slightly below the normal image size for my
machine - this gives much more consistent image sizes and compression
ratios, when compression is used. (The compression ratio during these
tests was always about 0.36).
Each line below is an average of two timings. I never saw any significant
difference when repeating measurements.
lzw: lzw compression
ew: early writeout
size: image size, MB
writeout/readin/total: time & speed of image save/load with compression
factored in.
test 1: ondemand cpu governor (800 MHz), 1% steps when doing early writeout
lzw ew size writeout readin total
s, MB/s s, MB/s s, MB/s
-------------------------------------------------------------------
N N 204.0 18.5, 11.1 11.0, 18.7 29.4, 13.9
N Y 203.8 10.0, 20.4 9.6, 21.5 19.5, 20.9
Y N 204.0 10.2, 20.1 3.6, 57.2 13.7, 29.7
Y Y 204.3 12.8, 16.0 3.5, 58.0 16.3, 25.1
Some initial conclusions:
- overall, using compression is faster on my machine.
- early writeout helps if compression isn't used, but hurts if it is
Next, I repeated all the above tests, but used the performance cpu governor
(2.2 GHz).
test 2: performance cpu governor (2.2 GHz), 1% steps when doing early writeout
lzw ew size writeout readin total
s, MB/s s, MB/s s, MB/s
-------------------------------------------------------------------
N N 204.0 15.0, 13.6 9.7, 21.2 24.7, 16.6
N Y 204.2 10.0, 20.5 9.6, 21.3 19.6, 20.9
Y N 204.1 9.2, 22.3 3.5, 58.1 12.7, 32.2
Y Y 204.2 11.1, 18.5 3.5, 58.0 14.6, 28.0
Unsurprising - with the cpu running faster, everything is sped up. lzf without
early writeout is still the winner.
After that, I put early writeout back to 20% increments and retested the
early-writeout runs at 2.2GHz:
test 3: performance cpu governor (2.2 GHz), 20% steps when doing early writeout
lzw ew size writeout readin total
s, MB/s s, MB/s s, MB/s
-------------------------------------------------------------------
N Y 203.8 9.1, 22.6 8.9, 22.8 18.0, 22.7
Y Y 204.2 10.2, 20.0 3.5, 57.7 13.8, 29.7
So triggering writeout less often is more efficient, but only slightly.
Jason
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
