On (25/03/08 18:41), Barry Song wrote: > 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. If compression kthread-s can run (have CPUs to be scheduled on). This looks a bit like a bottleneck. Is there anything that guarantees forward progress? Also, if compression kthreads constantly preempt kswapd, then it might not be worth it to have compression kthreads, I assume? If we have a pagefault and need to map a page that is still in the compression queue (not compressed and stored in zram yet, e.g. dut to scheduling latency + slow compression algorithm) then what happens?
