On Sat, 2025-03-08 at 18:41 +1300, Barry Song wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > 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? > Thank you for your explanation. Compared to the original single kswapd, we expect t1 to have a slight increase in re-scan time. However, since our kcompressd can focus on compression tasks and we can have multiple kcompressd instances (kcompressd0, kcompressd1, ...) running in parallel, we anticipate that the number of times a folio needs be re- scanned will not be too many. In our experiments, we fixed the CPU and DRAM at a certain frequency. We created a high memory pressure enviroment using a memory eater and recorded the increase in pgsteal_anon per second, which was around 300, 000. Then we applied our patch and measured again, that pgsteal_anon/s increased to over 800,000. > > > > > > > > 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. > Yes, we also hope to extend this to other swap devices, but currently, we have only modified zram. We are not very familiar with zswap and would like to ask if anyone has any suggestions for modifications? > Thanks > Barry Best Regards, Qun-wei
