On Sat, Mar 8, 2025 at 12:03 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > On Fri, Mar 7, 2025 at 4:02 AM Qun-Wei Lin <qun-wei.lin@xxxxxxxxxxxx> wrote: > > > > This patch series introduces a new mechanism called kcompressd to > > improve the efficiency of memory reclaiming in the operating system. The > > main goal is to separate the tasks of page scanning and page compression > > into distinct processes or threads, thereby reducing the load on the > > kswapd thread and enhancing overall system performance under high memory > > pressure conditions. > > Please excuse my ignorance, but from your cover letter I still don't > quite get what is the problem here? And how would decouple compression > and scanning help? My understanding is as follows: When kswapd attempts to reclaim M anonymous folios and N file folios, the process involves the following steps: * t1: Time to scan and unmap anonymous folios * t2: Time to compress anonymous folios * t3: Time to reclaim file folios Currently, these steps are executed sequentially, meaning the total time required to reclaim M + N folios is t1 + t2 + t3. However, Qun-Wei's patch enables t1 + t3 and t2 to run in parallel, reducing the total time to max(t1 + t3, t2). This likely improves the reclamation speed, potentially reducing allocation stalls. I don’t have concrete data on this. Does Qun-Wei have detailed performance data? > > > > > Problem: > > In the current system, the kswapd thread is responsible for both > > scanning the LRU pages and compressing pages into the ZRAM. This > > combined responsibility can lead to significant performance bottlenecks, > > What bottleneck are we talking about? Is one stage slower than the other? > > > especially under high memory pressure. The kswapd thread becomes a > > single point of contention, causing delays in memory reclaiming and > > overall system performance degradation. > > > > Target: > > The target of this invention is to improve the efficiency of memory > > reclaiming. By separating the tasks of page scanning and page > > compression into distinct processes or threads, the system can handle > > memory pressure more effectively. > > I'm not a zram maintainer, so I'm definitely not trying to stop this > patch. But whatever problem zram is facing will likely occur with > zswap too, so I'd like to learn more :) Right, this is likely something that could be addressed more generally for zswap and zram. Thanks Barry
