On (25/03/07 15:13), Nhat Pham wrote: > > > +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. I guess it also need to take swapoff into consideration (especially if it takes I/O from multiple sources)?
