Re: [PATCH v5 10/14] mm/mglru: simplify and improve dirty writeback handling

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 4/13/26 12:48 AM, Kairui Song via B4 Relay wrote:
> From: Kairui Song <kasong@tencent.com>
> 
> Right now the flusher wakeup mechanism for MGLRU is less responsive
> and unlikely to trigger compared to classical LRU. The classical
> LRU wakes the flusher if one batch of folios passed to shrink_folio_list
> is unevictable due to under writeback. MGLRU instead check and handle
> this after the whole reclaim loop is done.
> 
> We previously even saw OOM problems due to passive flusher, which were
> fixed but still not perfect [1].
> 
> We have just unified the dirty folio counting and activation routine,
> now just move the dirty flush into the loop right after shrink_folio_list.
> This improves the performance a lot for workloads involving heavy
> writeback and prepares for throttling too.
> 
> Test with YCSB workloadb showed a major performance improvement:
> 
> Before this series:
> Throughput(ops/sec): 62485.02962831822
> AverageLatency(us): 500.9746963330107
> pgpgin 159347462
> workingset_refault_file 34522071
> 
> After this commit:
> Throughput(ops/sec): 80857.08510208207
> AverageLatency(us): 386.653262968934
> pgpgin 112233121
> workingset_refault_file 19516246
> 
> The performance is a lot better with significantly lower refault. We also
> observed similar or higher performance gain for other real-world workloads.
> 
> We were concerned that the dirty flush could cause more wear for SSD:
> that should not be the problem here, since the wakeup condition is when
> the dirty folios have been pushed to the tail of LRU, which indicates
> that memory pressure is so high that writeback is blocking the workload
> already.
> 
> Reviewed-by: Axel Rasmussen <axelrasmussen@google.com>
> Link: https://lore.kernel.org/linux-mm/20241026115714.1437435-1-jingxiangzeng.cas@gmail.com/ [1]
> Signed-off-by: Kairui Song <kasong@tencent.com>
> ---

Thanks. Makes more sense to me. I also did some testing, and seems to 
work well.

Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>