From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 6B4BC22339 for ; Sun, 29 Mar 2026 08:21:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774772499; cv=none; b=Z+PzfF7ae1kBzjIOLDXbt2eJPPgdZgWMT64jQ7lAb+wHXb2bThciS2HRmj9EWR89WDH9EHwdoRgALrltB0yh9oupa58mRD2FUr10g0XqiqGdDnz7ij41ctzrC6Q5dbOMJKka5umlN2rotzWHWcCG2xLUyJdINgjL6LTaGDuNuTA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774772499; c=relaxed/simple; bh=V9Rak9CKvFFtccfqHlLtM0XujAEXpBfMHj7iZvpE+C4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L+9uNwM4LzuAljUxJiYzvxZbqrac9Fn4WZK7Yz7PPNydv7v1ZZf3ZJi7Co8YhPG/I0szilK3dskqS/hU1YoqZzVbcGoPUDLFiQARY3DkJImSYdDBcU3V/cfbaGKVEpF+aByvZPH10Jwp2CuEGH4T2RFqT2TQyyZRAoK1I1Epk/s= 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=g1O0A7zw; arc=none smtp.client-ip=209.85.210.179 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="g1O0A7zw" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-829781b2b01so1776784b3a.2 for ; Sun, 29 Mar 2026 01:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774772498; x=1775377298; 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=BtTGmq6mxA5M4Te1SDcD+20cKbTRttxCNlc+5BeOn9Q=; b=g1O0A7zwb8SzGKmWRfw4a3OLHn8m0dCAcDuOByISHx9atI8fw9/Qafwe746ZKkmEf+ 9ZqotyvpvlqjrGzCp2rJdg0p8X6uHPiTU0BA5MdUc0vxdKa8e7g9MmThH/RU0HJEOMyq gJ2BzGQ/1SOSCSUy8XfVuYBLgkrRrf1B8uZDRelTAUvgxt2csB88cQxmwc1z1ijs/OXv NziPqVXJYhpmpoP+6zn7GxFQrjKrUfLxk5Kx7XF9PfJesqOdmSyGS1+/sBot9NSbokn2 kV3HPMScAlWN7PlUnEyFULzrdj8v77EiHhZBvIUlrRRy8qf8Ed4hH5q/S5muBJvNDx4f mReQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774772498; x=1775377298; 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=BtTGmq6mxA5M4Te1SDcD+20cKbTRttxCNlc+5BeOn9Q=; b=LC303JoCYOXHC/XR8NtSb+c9Bq05ySDEpcpIfUTkymc80Jm6rOiiejZiMdmdNWqOnF UqwWmWQePH8LJF+7SpnMwwiuTn2v+dml4vRsBZpfmccEHyhOMAU24vlgr2RQ+pw2wIjw Op0woAjE9YiZk1E6KmDJxT7RVe2o1zacW1TEvT4KCZb66bJvbDdJadx9tnA2fCtkcGuD Crn1OSPVj1kmEhEm4CDqAUGOjc/bLQ+7++FWUw6rRQGQG4JUSvdGvA7VmY1oqo0snSiY 1e5OPY0lF8oe78u+Xefm9MA+7ad9Km7nJZpyx0ShwzTztLl3W4AHFJCWvsfYPftaxYNc w3RQ== X-Forwarded-Encrypted: i=1; AJvYcCXL8HA7fkXhryhf7zmABhbnudVSg73d9NJ0sVYxCYMvf0tEDUIdEG5YO1/i2LkTgvpJ5pncM05d51I6mEg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+hK7xzT73mGLz/gNbJOcTcXsvYfeGNFz01U9UpBsk4I3IPZ0p drGqTLGu8zrlmGDtj+U4PAElRIKb+WEpRAq/8/QBdxIA/X4H7enQ5/yb X-Gm-Gg: ATEYQzwGanWNAiSkDX9lNuGxaocUez0+Esif1lw41KOUlfsFQfVqjQoig85qwR/FB7n eMgdJNJ7z1+ywUP29w5jiNs6kdUjIT5w5D0StIHonMXyuzEOLpvwy7BxYN86UaAfL4RnUq/vCxG qlIuAYbgvvsr2MmIWDa5dpmkMAHblGHMUDAx+HyIDyUuUVgL6DdECTqqXYHjBKIT94NfsW93Xok sKO5mpslJb9+hkgZcH+62bJD0a3JtYIMSaWJkJ2VMHwXAG38i8RLOCXYwm0wYxM/Txma0OW31pr XARpoLGOuKc7c7sw33cg797UqtYPFzqVpcykI2EMxX+8y82QQEG6wjt/BNZwW6TWckQASHK1YtP gzikR38qK0HM+2ThJm6EoPLUk0MelmN0wFDaNzZ4vfGjQCUEFo+7MppLe5WqOs8BaPMaBy4pkze 2YDp3lprEVc8ENG1IicR5KY5L5VFTFTTTjmzrpPJQz4nSxjtdWDYmqm43xwqc= X-Received: by 2002:a05:6a00:bc90:b0:829:803e:6798 with SMTP id d2e1a72fcca58-82c96038f67mr7975297b3a.56.1774772497553; Sun, 29 Mar 2026 01:21:37 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82ca843db09sm4386606b3a.7.2026.03.29.01.21.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Mar 2026 01:21:37 -0700 (PDT) Date: Sun, 29 Mar 2026 16:21:29 +0800 From: Kairui Song To: linux-mm@kvack.org Cc: kasong@tencent.com, 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 , 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: <20260329-mglru-reclaim-v2-8-b53a3678513c@tencent.com> Forwarding sashiko review: https://sashiko.dev/#/message/20260329-mglru-reclaim-v2-8-b53a3678513c%40tencent.com > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 8de5c8d5849e..17b5318fad39 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > [ ... ] > > @@ -4633,21 +4632,6 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > > return true; > > } > > > > - dirty = folio_test_dirty(folio); > > - writeback = folio_test_writeback(folio); > > - if (type == LRU_GEN_FILE && dirty) { > > - sc->nr.file_taken += delta; > > - if (!writeback) > > - sc->nr.unqueued_dirty += delta; > > - } > > - > > - /* waiting for writeback */ > > - if (writeback || (type == LRU_GEN_FILE && dirty)) { > > - gen = folio_inc_gen(lruvec, folio, true); > > - list_move(&folio->lru, &lrugen->folios[gen][type][zone]); > > - return true; > > - } > > - > > return false; > > } > > Could removing this proactive promotion cause a livelock and premature OOM > during GFP_NOIO or GFP_NOFS direct reclaim? > Without this check, dirty file folios fall through to isolate_folio(). If > the reclaim does not have __GFP_IO, isolate_folio() will skip them. > These skipped folios are spliced back to the front of the oldest generation > list in scan_folios(). Because isolate_folio() isolates 0 folios, > evict_folios() returns early. > This completely bypasses the new wakeup_flusher_threads() call, leaving the > dirty folios unqueued for writeback, and the oldest generation can never > advance. This is a nice found. For GFP_NOIO (or actually !__GFP_IO), we also need to active and set reclaim for the dirty folios. It's a narrow case though. Following update should work: diff --git a/mm/vmscan.c b/mm/vmscan.c index 8170aee096e9..342ba3afe77c 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4641,8 +4641,7 @@ static bool isolate_folio(struct lruvec *lruvec, struct folio *folio, struct sca /* swap constrained */ if (!(sc->gfp_mask & __GFP_IO) && - (folio_test_dirty(folio) || - (folio_test_anon(folio) && !folio_test_swapcache(folio)))) + (folio_test_anon(folio) && !folio_test_swapcache(folio))) return false; > [ ... ] > > @@ -4858,12 +4840,27 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > > return scanned; > > retry: > > reclaimed = shrink_folio_list(&list, pgdat, sc, &stat, false, memcg); > > - sc->nr.unqueued_dirty += stat.nr_unqueued_dirty; > > sc->nr_reclaimed += reclaimed; > > trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id, > > type_scanned, reclaimed, &stat, sc->priority, > > type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON); > > > > + /* > > + * If too many file cache in the coldest generation can't be evicted > > + * due to being dirty, wake up the flusher. > > + */ > > + if (stat.nr_unqueued_dirty == isolated) { > > Is the isolated variable stale when evaluated on the retry path? > If evict_folios() jumps back to the retry label, shrink_folio_list() > processes a smaller list of only clean folios. The isolated variable retains > the size of the original list, while stat.nr_unqueued_dirty can only be as > large as the new, smaller list. > Does this logically impossible condition cause any unintended behavior, or > should the check be moved outside the retry loop to avoid confusion? This is fine, stat.nr_unqueued_dirty is always smaller than isolated. The "retry" label above only used to handle some folios that are failed to be reclaimed after isolation. Meanwhile I do think we should clean up this retry logic as it will also confuse the tracepoint. Better do it later.