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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d73e19b-f264-4c31-8f5a-fb17b6bc0600@cirno.name>
Date: Sat, 7 Dec 2024 04:16:29 +0800
From: LiviaMedeiros <9@...no.name>
To: Sergey Senozhatsky <senozhatsky@...omium.org>,
 Minchan Kim <minchan@...nel.org>
Cc: Jens Axboe <axboe@...nel.dk>, Nick Terrell <terrelln@...com>,
 linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: [PATCH] zram: make default ZSTD compression level configurable

From: LiviaMedeiros <livia@...no.name>

Add support for configuring the default ZSTD compression level for zram
devices via the CONFIG_ZRAM_DEFAULT_ZSTD_LEVEL configuration option.
If this option is not set, fallback to zstd_default_clevel() is used.

Signed-off-by: LiviaMedeiros <livia@...no.name>
---
Disclaimer:
This probably should be implemented in userspace, I failed to find 
relevant options in zram-init (v11.1) scripts nor zramctl (v2.40.2) utility.
I also failed to make something like `echo "algo=zstd level=9" > 
/sys/block/zram3/algorithm_params` work in runtime, but I assume I'm 
just dumb and/or it requires extra steps.

Nevertheless IMHO it makes sense to set defaults in kernel config: when 
kernel is built for specific hardware, it would be handy to adjust it 
depending on amount of extra CPU power or extra RAM.
The main usecase for adjusting the compression level that I see is 
making zram device capable of holding _a lot_ of transparently 
compressed text data, fitting into RAM at the cost of additional CPU time.
Hence this patch implements this only for zstd backend, which provides 
the best compression ratio potential (perhaps implementing xz/LZMA2 
backend would also help with it).
If this approach looks feasible, it can be expanded to other algos as well.

I'm open for any suggestions.
---
  drivers/block/zram/Kconfig        | 10 ++++++++++
  drivers/block/zram/backend_zstd.c |  8 +++++++-
  2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index 402b7b175863..8a5e6da39834 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -32,6 +32,16 @@ config ZRAM_BACKEND_ZSTD
  	select ZSTD_COMPRESS
  	select ZSTD_DECOMPRESS

+config ZRAM_DEFAULT_ZSTD_LEVEL
+	int "Default zstd compression level"
+	depends on ZRAM_BACKEND_ZSTD
+	range 1 22
+	default 3
+	help
+	  Sets the default compression level for zstd compression in zram.
+	  The value can range from 1 (fastest) to 22 (maximum compression).
+	  If not set, the system uses the zstd default (typically 3).
+
  config ZRAM_BACKEND_DEFLATE
  	bool "deflate compression support"
  	depends on ZRAM
diff --git a/drivers/block/zram/backend_zstd.c 
b/drivers/block/zram/backend_zstd.c
index 1184c0036f44..af7b919ec11c 100644
--- a/drivers/block/zram/backend_zstd.c
+++ b/drivers/block/zram/backend_zstd.c
@@ -7,6 +7,12 @@

  #include "backend_zstd.h"

+#ifdef CONFIG_ZRAM_DEFAULT_ZSTD_LEVEL
+#define ZRAM_DEFAULT_ZSTD_LEVEL CONFIG_ZRAM_DEFAULT_ZSTD_LEVEL
+#else
+#define ZRAM_DEFAULT_ZSTD_LEVEL zstd_default_clevel()
+#endif
+
  struct zstd_ctx {
  	zstd_cctx *cctx;
  	zstd_dctx *dctx;
@@ -68,7 +74,7 @@ static int zstd_setup_params(struct zcomp_params *params)

  	params->drv_data = zp;
  	if (params->level == ZCOMP_PARAM_NO_LEVEL)
-		params->level = zstd_default_clevel();
+		params->level = ZRAM_DEFAULT_ZSTD_LEVEL;

  	zp->cprm = zstd_get_params(params->level, PAGE_SIZE);

-- 
2.47.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ