On Fri, Mar 7, 2025 at 11:41 AM Barry Song <21cnbao@xxxxxxxxx> wrote: > > On Sat, Mar 8, 2025 at 1:02 AM Qun-Wei Lin <qun-wei.lin@xxxxxxxxxxxx> wrote: > > > > Introduced Kcompressd to offload zram page compression, improving > > system efficiency by handling compression separately from memory > > reclaiming. Added necessary configurations and dependencies. > > > > Signed-off-by: Qun-Wei Lin <qun-wei.lin@xxxxxxxxxxxx> > > --- > > drivers/block/zram/Kconfig | 11 ++ > > drivers/block/zram/Makefile | 3 +- > > drivers/block/zram/kcompressd.c | 340 ++++++++++++++++++++++++++++++++ > > drivers/block/zram/kcompressd.h | 25 +++ > > drivers/block/zram/zram_drv.c | 22 ++- > > 5 files changed, 397 insertions(+), 4 deletions(-) > > create mode 100644 drivers/block/zram/kcompressd.c > > create mode 100644 drivers/block/zram/kcompressd.h > > > > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig > > index 402b7b175863..f0a1b574f770 100644 > > --- a/drivers/block/zram/Kconfig > > +++ b/drivers/block/zram/Kconfig > > @@ -145,3 +145,14 @@ config ZRAM_MULTI_COMP > > re-compress pages using a potentially slower but more effective > > compression algorithm. Note, that IDLE page recompression > > requires ZRAM_TRACK_ENTRY_ACTIME. > > + > > +config KCOMPRESSD > > + tristate "Kcompressd: Accelerated zram compression" > > + depends on ZRAM > > + help > > + Kcompressd creates multiple daemons to accelerate the compression of pages > > + in zram, offloading this time-consuming task from the zram driver. > > + > > + This approach improves system efficiency by handling page compression separately, > > + which was originally done by kswapd or direct reclaim. > > For direct reclaim, we were previously able to compress using multiple CPUs > with multi-threading. > After your patch, it seems that only a single thread/CPU is used for compression > so it won't necessarily improve direct reclaim performance? > > Even for kswapd, we used to have multiple threads like [kswapd0], [kswapd1], > and [kswapd2] for different nodes. Now, are we also limited to just one thread? > I also wonder if this could be handled at the vmscan level instead of the zram > level. then it might potentially help other sync devices or even zswap later. Agree. A shared solution would be much appreciated. We can keep the kcompressd idea, but have it accept IO work from multiple sources (zram, zswap, whatever) through a shared API. Otherwise we would need to reinvent the wheel multiple times :)
