[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c01666b-5f2b-616b-7f07-3c7603ce1bb1@quicinc.com>
Date: Tue, 3 Oct 2023 13:35:10 +0530
From: Nikhil V <quic_nprakash@...cinc.com>
To: Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
"Rafael J. Wysocki" <rafael@...nel.org>
CC: Jonathan Corbet <corbet@....net>,
Catalin Marinas <catalin.marinas@....com>,
Randy Dunlap <rdunlap@...radead.org>,
"Peter Zijlstra" <peterz@...radead.org>,
"Steven Rostedt (Google)" <rostedt@...dmis.org>,
"Paul E. McKenney" <paulmck@...nel.org>, Tejun Heo <tj@...nel.org>,
<linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-pm@...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: [RFC PATCH 0/4] PM: hibernate: LZ4 compression support
On 9/26/2023 2:27 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.
>
> 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 | 25 ++-
> kernel/power/hibernate.c | 83 +++++++-
> kernel/power/power.h | 19 ++
> kernel/power/swap.c | 189 +++++++++++-------
> 5 files changed, 248 insertions(+), 74 deletions(-)
>
Hi,
Could you please let me know if you have any concerns/comments on this
approach? If there are no comments, I could push another patch series
with PATCH tag for review.
Thanks
Nikhil V
Powered by blists - more mailing lists