2011/12/29 Bojan Smojver <bojan@xxxxxxxxxxxxx>: > 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
