| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 22 Jan 2024 18:48:14 +0530
From: Nikhil V <quic_nprakash@...cinc.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
"Jonathan
Corbet" <corbet@....net>,
Randy Dunlap <rdunlap@...radead.org>,
Peter
Zijlstra <peterz@...radead.org>,
"Steven Rostedt (Google)"
<rostedt@...dmis.org>,
Tejun Heo <tj@...nel.org>, "Paul E. McKenney"
<paulmck@...nel.org>,
"Catalin Marinas" <catalin.marinas@....com>,
<linux-pm@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <quic_pkondeti@...cinc.com>,
<quic_kprasan@...cinc.com>, <quic_mpilaniy@...cinc.com>,
<quic_shrekk@...cinc.com>, <mpleshivenkov@...gle.com>,
<ericyin@...gle.com>
Subject: Re: [PATCH RESEND v2 0/4] PM: hibernate: LZ4 compression support
On 1/22/2024 5:46 PM, Rafael J. Wysocki wrote:
> On Mon, Jan 22, 2024 at 1:14 PM Nikhil V <quic_nprakash@...cinc.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@...cinc.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/@...el/@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
Powered by blists - more mailing lists