Messages in this thread |  | | Date | Mon, 22 Jan 2024 18:48:14 +0530 | | Subject | Re: [PATCH RESEND v2 0/4] PM: hibernate: LZ4 compression support | | From | Nikhil V <> |
| |
On 1/22/2024 5:46 PM, Rafael J. Wysocki wrote: > On Mon, Jan 22, 2024 at 1:14 PM Nikhil V <quic_nprakash@quicinc.com> wrote: >> >> >> >> On 12/12/2023 6:14 PM, Rafael J. Wysocki wrote: >>> Hi, >>> >>> On Wed, Nov 29, 2023 at 11:20 AM Nikhil V <quic_nprakash@quicinc.com> wrote: >>>> >>>> >>>> On 11/15/2023 5:52 PM, Nikhil V wrote: >>>>> This patch series covers the following: >>>>> 1. Renaming lzo* to generic names, except for lzo_xxx() APIs. This is >>>>> used in the next patch where we move to crypto based APIs for >>>>> compression. There are no functional changes introduced by this >>>>> approach. >>>>> >>>>> >>>>> 2. Replace LZO library calls with crypto generic APIs >>>>> >>>>> Currently for hibernation, LZO is the only compression algorithm >>>>> available and uses the existing LZO library calls. However, there >>>>> is no flexibility to switch to other algorithms which provides better >>>>> results. The main idea is that different compression algorithms have >>>>> different characteristics and hibernation may benefit when it uses >>>>> alternate algorithms. >>>>> >>>>> By moving to crypto based APIs, it lays a foundation to use other >>>>> compression algorithms for hibernation. >>>>> >>>>> >>>>> 3. LZ4 compression >>>>> >>>>> Extend the support for LZ4 compression to be used with hibernation. >>>>> The main idea is that different compression algorithms have different >>>>> characteristics and hibernation may benefit when it uses any of these >>>>> algorithms: a default algorithm, having higher compression rate but is >>>>> slower(compression/decompression) and a secondary algorithm, that is >>>>> faster(compression/decompression) but has lower compression rate. >>>>> >>>>> LZ4 algorithm has better decompression speeds over LZO. This reduces >>>>> the hibernation image restore time. >>>>> As per test results: >>>>> LZO LZ4 >>>>> Size before Compression(bytes) 682696704 682393600 >>>>> Size after Compression(bytes) 146502402 155993547 >>>>> Decompression Rate 335.02 MB/s 501.05 MB/s >>>>> Restore time 4.4s 3.8s >>>>> >>>>> LZO is the default compression algorithm used for hibernation. Enable >>>>> CONFIG_HIBERNATION_DEF_COMP_LZ4 to set the default compressor as LZ4. >>>>> >>>>> Compression Benchmarks: https://github.com/lz4/lz4 >>>>> >>>>> >>>>> 4. Support to select compression algorithm >>>>> >>>>> Currently the default compression algorithm is selected based on >>>>> Kconfig. Introduce a kernel command line parameter "hib_compression" to >>>>> override this behaviour. >>>>> >>>>> Users can set "hib_compression" command line parameter to specify >>>>> the algorithm. >>>>> Usage: >>>>> LZO: hib_compression=lzo >>>>> LZ4: hib_compression=lz4 >>>>> LZO is the default compression algorithm used with hibernation. >>>>> >>>>> >>>>> Changes in v2: >>>>> - Fixed build issues reported by kernel test robot for ARCH=sh, [1]. >>>>> [1] https://lore.kernel.org/oe-kbuild-all/202310171226.pLUPeuC7-lkp@intel.com/ >>>>> >>>>> Nikhil V (4): >>>>> PM: hibernate: Rename lzo* to make it generic >>>>> PM: hibernate: Move to crypto APIs for LZO compression >>>>> PM: hibernate: Add support for LZ4 compression for hibernation >>>>> PM: hibernate: Support to select compression algorithm >>>>> >>>>> .../admin-guide/kernel-parameters.txt | 6 + >>>>> kernel/power/Kconfig | 26 ++- >>>>> kernel/power/hibernate.c | 85 +++++++- >>>>> kernel/power/power.h | 19 ++ >>>>> kernel/power/swap.c | 189 +++++++++++------- >>>>> 5 files changed, 251 insertions(+), 74 deletions(-) >>>>> >>>>> >>>>> base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86 >>>> >>>> Hi @Rafael/@Pavel/@Len, >>>> >>>> Could you please let me know if you have any concerns on this approach? >>> >>> Not really a concern, but that is a significant change that I would >>> rather make early in the cycle, which means after the 6.8 merge >>> window. >>> >>> No need to resend unless there is something to address in which case >>> I'll let you know. >>> >>> Thanks! >>> >>>> FYI: We have tested this on QEMU and its working fine. >>>> >>>> Logs(suspend): >>>> [ 75.242227] PM: Using 3 thread(s) for lz4 compression >>>> [ 75.243043] PM: Compressing and saving image data (17495 pages)... >>>> [ 75.243917] PM: Image saving progress: 0% >>>> [ 75.261727] PM: Image saving progress: 10% >>>> [ 75.277968] PM: Image saving progress: 20% >>>> [ 75.290927] PM: Image saving progress: 30% >>>> [ 75.305186] PM: Image saving progress: 40% >>>> [ 75.318252] PM: Image saving progress: 50% >>>> [ 75.330310] PM: Image saving progress: 60% >>>> [ 75.345906] PM: Image saving progress: 70% >>>> [ 75.359054] PM: Image saving progress: 80% >>>> [ 75.372176] PM: Image saving progress: 90% >>>> [ 75.388411] PM: Image saving progress: 100% >>>> [ 75.389775] PM: Image saving done >>>> [ 75.390397] PM: hibernation: Wrote 69980 kbytes in 0.14 seconds >>>> (499.85 MB/s) >>>> [ 75.391591] PM: Image size after compression: 28242 kbytes >>>> [ 75.393089] PM: S| >>>> [ 75.399784] sd 0:0:0:0: [sda] Synchronizing SCSI cache >>>> [ 75.439170] sd 0:0:0:0: [sda] Stopping disk >>>> [ 75.501461] ACPI: PM: Preparing to enter system sleep state S5 >>>> [ 75.502766] reboot: Power down >>>> >>>> >>>> >>>> Logs(resume): >>>> [ 1.063248] PM: hibernation: resume from hibernation >>>> [ 1.072868] Freezing user space processes >>>> [ 1.073707] Freezing user space processes completed (elapsed 0.000 >>>> seconds) >>>> [ 1.075192] OOM killer disabled. >>>> [ 1.075837] Freezing remaining freezable tasks >>>> [ 1.078010] Freezing remaining freezable tasks completed (elapsed >>>> 0.001 seconds) >>>> [ 1.087489] PM: Using 3 thread(s) for lz4 decompression >>>> [ 1.088570] PM: Loading and decompressing image data (17495 pages)... >>>> [ 1.125549] PM: Image loading progress: 0% >>>> [ 1.190380] PM: Image loading progress: 10% >>>> [ 1.204963] PM: Image loading progress: 20% >>>> [ 1.218988] PM: Image loading progress: 30% >>>> [ 1.233697] PM: Image loading progress: 40% >>>> [ 1.248658] PM: Image loading progress: 50% >>>> [ 1.262910] PM: Image loading progress: 60% >>>> [ 1.276966] PM: Image loading progress: 70% >>>> [ 1.290517] PM: Image loading progress: 80% >>>> [ 1.305427] PM: Image loading progress: 90% >>>> [ 1.320666] PM: Image loading progress: 100% >>>> [ 1.321866] PM: Image loading done >>>> [ 1.322599] PM: hibernation: Read 69980 kbytes in 0.23 seconds >>>> (304.26 MB/s) >>>> [ 1.324795] printk: Suspending console(s) (use no_console_suspend to >>>> debug) >>>> [ 74.943801] ata1.00: Entering standby power mode >>>> >>>> >>>> Thanks, >>>> Nikhil V >> >> >> Hi @Rafael >> >> We have picked this patch series on 6.8-rc1 and tested the functionality >> on QEMU. Its working fine. However, while applying the patches we could >> see minor conflicts. Could you please let me know if we need to push a >> new version after resolving these conflicts? > > It will help. > > I can resolve the conflicts, but I may make mistakes in the process. > > Thanks!
Thanks for the response. Will push a new version after resolving the conflicts.
Thanks, Nikhil V
|  |