[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240207065751.1908939-1-senozhatsky@chromium.org>
Date: Wed, 7 Feb 2024 15:57:10 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: [RFC][PATCH 0/2] zram: decouple comp stream and comp buffer
RFC
We keep compression work memory buffer per-comp stream (which
is per-CPU), but we don't need that many buffers, because on each
CPU only one compression backend can access work memory at any given
time. Hence the patch series moves compression work memory to a
dedicated per-CPU area, reducing the amount of memory we allocate
for those buffers.
For instance, assume a 12 CPUs system, 2 compression streams
per-CPU (a default and one for deferred recompression). Before
we'd allocate 12 * 2 * 2 pages, after we'll allocate 12 * 2 pages.
NOTE:
The series stops short of moving comp buffers to a global per-CPU
area, which all zram devices can share. Compression backends use
CPUs exclusively (disable migration and CPU hotplug), so in theory
comp work memory can be in global per-CPU data. This can reduce
memory usage on systems that init numerous zram devices.
E.g. instead of num-zram-devices * num-cpus buffers we'll allocate
only num-cpus buffers.
Sergey Senozhatsky (2):
zram: do not allocate buffer if crypto comp allocation failed
zram: move comp buffer to a dedicate per-CPU area
drivers/block/zram/zcomp.c | 118 +++++++++++++++++++++++++++++-----
drivers/block/zram/zcomp.h | 24 +++++--
drivers/block/zram/zram_drv.c | 32 +++++++--
drivers/block/zram/zram_drv.h | 1 +
include/linux/cpuhotplug.h | 1 +
5 files changed, 151 insertions(+), 25 deletions(-)
--
2.43.0.594.gd9cf4e227d-goog
Powered by blists - more mailing lists