From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 072DF2D838E for ; Wed, 15 Apr 2026 03:25:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223544; cv=none; b=N2AZNHCHZ8hLOxIyJb3CQL/yMwvvBAOqGxq46sXeNEuhO11h64+enqvx7itvgtU0LRixmeQss2gHJ+UIjcdRzWPb9+JeJ0u8oqPnqtTwtfGpfTnfYlOKPRs+FN5wYpp8kTB+L5UpHYUOpNzc18mwQtHWwKqka/4blmojYKR5rl8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223544; c=relaxed/simple; bh=nlSOVqTUhg3keBB4rfBEWktw+H3CyqV0KXxCdo+oxQU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=erdlqfjLI4Fh948zVBr1K9I5T7QtSBs8LTmauaG7YJ1aFmdJN0U/BEDPM/H+UBX2w010txxuVWIFVMHd5Onn5W+gv3SdGOGTSVf1fjvguRAaKYXaS9mPO4vAK9Muv02wkIodjF68fPjx5u7Z4zf46rRaS4HF47EzChdv0iWZSSw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Upoozw3q; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Upoozw3q" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776223539; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=H8E3xMwG6jp03zBQXo4a+PQQm0Lb5d/w1uPUEFDcne8=; b=Upoozw3q2GK35Ua0yC+5u1WJGlGC0paWRvY2EakAUKuvTCYBuDPzCoFodfH7pmnsgWNQ1w3iGYeLIk90lT/l3F+wO3Q+ycGWlv/qa54PeA84tlabjM+17c3dT9uB3+2TLuV+rWsdXD+ZG8WGqMDWghkJgmyAE36zT7xZ4J6ERzs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R251e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=25;SR=0;TI=SMTPD_---0X138zqv_1776223535; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X138zqv_1776223535 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 11:25:37 +0800 Message-ID: Date: Wed, 15 Apr 2026 11:25:35 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 10/14] mm/mglru: simplify and improve dirty writeback handling To: kasong@tencent.com, linux-mm@kvack.org Cc: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org, Qi Zheng References: <20260413-mglru-reclaim-v5-0-8eaeacbddc44@tencent.com> <20260413-mglru-reclaim-v5-10-8eaeacbddc44@tencent.com> From: Baolin Wang In-Reply-To: <20260413-mglru-reclaim-v5-10-8eaeacbddc44@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/13/26 12:48 AM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > 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 > Link: https://lore.kernel.org/linux-mm/20241026115714.1437435-1-jingxiangzeng.cas@gmail.com/ [1] > Signed-off-by: Kairui Song > --- Thanks. Makes more sense to me. I also did some testing, and seems to work well. Reviewed-by: Baolin Wang