From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B84D3CCA12 for ; Thu, 2 Apr 2026 11:44:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775130306; cv=none; b=uFJqPwnL67coFyiLN2jv7z5KEP40JTINibLkqdaMCXiN5GsmayW7VBsEFPY5Y+RXEdi0Ar1W9P51GNeDwOZfwrUa2gfsBjMztJ+/3jqSMRH8ChHf9qeopoZhxLg5+i92rguEu3EKrWH9lCYRHUkDKjPkdMek3yFWQGR9392xj/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775130306; c=relaxed/simple; bh=ESTogprcZ7byffey0Ro0F8ZVSVw/l709sxLd/B1uyYg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QR1dRkfg63VQuZ3QuxLaAauvOE8MJyjR94gAaidpydM1cxyoUxCs67gqt/XgFlSjJ9x2K3MJyut2megH6IffW0IuDccAT95YstydBvdr9dueinKRyRTj5MrvRl8YNzBiRfHa/OXXRpZj+ZiRaJR8nWymd6fz80WVFRjLHRE7THQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bwHEaVdE; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bwHEaVdE" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ab46931cf1so13086245ad.0 for ; Thu, 02 Apr 2026 04:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775130296; x=1775735096; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2QHCVOKZe5aOuuGBELCvMiQhEHXDG+VGl4rmeomtG+0=; b=bwHEaVdE9Yk4KhVxFuBLkDh81ZTS/a9fqJKJfZb5vRYbFM2OOVOzgqqJ6YbK4qzXsV fR1wbwkDq/I6apfWnJzCWbjyUtFijQQns/CKvq8lUCO8N5XIvzDsriM0hiQREq1M3J+X AqQof1GIJKhwbUr71wKoAFrC09zRa7FdOoZ+kgrqiy0rL2TLC6zHprMq9qMRSkxuG9zP 3vZv4lTJ1CJitt6akLTCIO2u8+Mob0okSmMJD4IFcgX67cA252OgE2ZyAMgyedXBZO63 Q7SEcgkPpCvqV6yKHSBHrq5XD+PtEyL5RnTuoOiYPISBZ+ZxAPm7J2JHP4vZ+g9dJTQh 218A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775130296; x=1775735096; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2QHCVOKZe5aOuuGBELCvMiQhEHXDG+VGl4rmeomtG+0=; b=skaPe5DxxTNGHZdxCy0dCYhoM7sYkCve6ZIF05n5OIwuguL2RLukil4DHdAJVS9/aE 1K+FNrwywKdUc8XgZadOpFooIxqpKAKBhe09f/H93JtLvNR/VkCt4ygf0O5FcPMkWTzB eGA5RHhr1jWqIgGufVpB0Hm/o+zYTyyriejv6aVnyJQNr+iSZ4ZUYSIsyo0iA43jbB4h SQA7dH5MKIGfKKY423jPgc3MOa7JoHgxupgf+UJNsw9xS1l54tXvNl1GmEbzMsNoPSu8 SSMSZDG06AwhCggWfhZOuiL42huADJ2LUSfK8PmXIHBAAdVFCWw28TrmherVILo9irK1 f7Uw== X-Forwarded-Encrypted: i=1; AJvYcCXDP2xGd7j5wak2r/3G3RBcsDKmE/BY1qL/eOg4fg0hd4cAlSibyKboM4dkw+IxWJ/0BO/+7pfslnpVlwE=@vger.kernel.org X-Gm-Message-State: AOJu0YxB22HIDoLcYY7wqsXel3Nv58JmduP7JU5bBKlnZRNNgnNw+rXH ci95u21BWElg4jn+cY3R70Z5fQSvPeMsIRhvUQ0eiBdf3fwzeJlVbjwe X-Gm-Gg: AeBDies/iVe7M/8X+eg3wpjHRAKGzICt9wKBgCXgLLbsMxmkY1rVVLz6J7nb7u+n2fw ODLwg+I94uTtsGK3NhuY7EeKU7EMQebwN9tDMcQtkdc+22toiqVpEwmzdP6K54NlbGS0GGif44U VPzYxlnTiWTKMuG8nvuXTlaPXjjao7Na96ZumIGiA0dRJbqxuTvyjLx3RfUUqZodM42gizNlu3e //pVJBZ0UQVjW47KhhUfREAu+nzCO763bAjul11+YtOjVZGV7FukYCsDo+EiRYvJjh/Z/OqhOGM BMrhfbqWX/35VRrFCYNOpOS+jwSKP5sM8PJDte4Jujlzo+pBZEiwu97qZd5hdh31dYh8Cjv3Nr8 Mavtrt/RUCuL9hJ77NRFjioOpXeQr0tE1PZsVOVuud2eghhIB6jBmF7jK5WS2u+MvBUzkQvLhWy T4dEXkGxZZX8FcVNuVXH0uT7N6xEZytUeUafdOfI3mkSjY4EWzDrCCujhNihnxP75r2i766ixv6 W1UK/8= X-Received: by 2002:a17:902:da8a:b0:2b2:54db:3e93 with SMTP id d9443c01a7336-2b277e52a17mr19766245ad.23.1775130296027; Thu, 02 Apr 2026 04:44:56 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.21]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b27478b658sm28523085ad.31.2026.04.02.04.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 04:44:55 -0700 (PDT) Date: Thu, 2 Apr 2026 19:44:47 +0800 From: Kairui Song To: Shakeel Butt Cc: kasong@tencent.com, linux-mm@kvack.org, Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , 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 , Baolin Wang Subject: Re: [PATCH v2 08/12] mm/mglru: simplify and improve dirty writeback handling Message-ID: References: <20260329-mglru-reclaim-v2-0-b53a3678513c@tencent.com> <20260329-mglru-reclaim-v2-8-b53a3678513c@tencent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Apr 01, 2026 at 04:37:14PM +0800, Shakeel Butt wrote: > On Sun, Mar 29, 2026 at 03:52:34AM +0800, Kairui Song via B4 Relay wrote: > > From: Kairui Song > > > > The current handling of dirty writeback folios is not working well for > > file page heavy workloads: Dirty folios are protected and move to next > > gen upon isolation of getting throttled or reactivation upon pageout > > (shrink_folio_list). > > > > This might help to reduce the LRU lock contention slightly, but as a > > result, the ping-pong effect of folios between head and tail of last two > > gens is serious as the shrinker will run into protected dirty writeback > > folios more frequently compared to activation. The dirty flush wakeup > > condition is also much more passive compared to active/inactive LRU. > > Active / inactve LRU wakes the flusher if one batch of folios passed to > > shrink_folio_list is unevictable due to under writeback, but MGLRU > > instead has to check this after the whole reclaim loop is done, and then > > count the isolation protection number compared to the total reclaim > > number. > > I was just ranting about this on Baolin's patch and thanks for unifying them. > > > > > And we previously saw OOM problems with it, too, which were fixed but > > still not perfect [1]. > > > > So instead, just drop the special handling for dirty writeback, just > > re-activate it like active / inactive LRU. And also move the dirty flush > > wake up check right after shrink_folio_list. This should improve both > > throttling and performance. > > Please divide this patch into two separate ones. One for moving the flusher > waker (& v1 throttling) within evict_folios() and second the above heuristic of > dirty writeback. OK, but throttling is not handled by this commit, it handled by the last commit. And using the common routine in shrink_folio_list and activate the folio is suppose to be done before moving the flusher wakeup and throttle, as I observed some inefficient reclaim or over aggressive / passive if we don't do that first. We will run into these folios again and again very frequently and shrink_folio_list also have better dirty / writeback detection. I tested these two changes separately again in case I remembered it wrongly, using the MongoDB YCSB case: Before this series or commit, it's similar: Throughput(ops/sec), 63414.891930455 Apply only the remove folio_inc_gen and use shrink_folio_list to active folio part in this commit: Throughput(ops/sec), 68580.83394294075 Skip the folio_inc_gen part but apply other part: Throughput(ops/sec), 61614.29451632779 After the two fixes together (apply this commit fully): Throughput(ops/sec), 80857.08510208207 And the whole series: Throughput(ops/sec), 79760.71784646061 The test is a bit noisy, but after the whole series the throttling seems is already slightly slowing down the workload, still accetable IMO, this is also why activate the folios here is a good idea or we will run into problematic throttling. I think this can be further improved later, as I observed previously with the LFU alike rework I mentioned, it will help promote folios more proactively to younger gen and it will have a even better performance: https://lore.kernel.org/linux-mm/CAMgjq7BoekNjg-Ra3C8M7=8=75su38w=HD782T5E_cxyeCeH_g@mail.gmail.com/ For now I can split this into two in V3, first a commit to use the common routine for activating the folio, then move then fluster wakeup.