| Message ID | cover.1700048610.git.quic_nprakash@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PM: hibernate: LZ4 compression support | expand |
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? 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, 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
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? Thanks, Nikhil V
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!
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
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