From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5887C02180 for ; Wed, 15 Jan 2025 04:28:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 640AD6B008C; Tue, 14 Jan 2025 23:28:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F0666B0092; Tue, 14 Jan 2025 23:28:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 490AF6B0093; Tue, 14 Jan 2025 23:28:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2B2136B008C for ; Tue, 14 Jan 2025 23:28:45 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C3B501C8089 for ; Wed, 15 Jan 2025 04:28:44 +0000 (UTC) X-FDA: 83008405368.11.AE089EE Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf08.hostedemail.com (Postfix) with ESMTP id E000D16000F for ; Wed, 15 Jan 2025 04:28:42 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nLUin7Lz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736915322; a=rsa-sha256; cv=none; b=DFgQXvYoJaeK85YJx4mYt9rXTXZkOlrij1F9+CdknMy1INlBxAU9/zjGiA5tGi18I0t3Cy pDfNVqKY+xc2FPR9lf//iJpRdwk33cpYnwf6A749jldi/R3WNa9FHus6WYIDFBQOdIU+fi 6+79ZEp4wat0AvJZpKHUe9zus+EhIGM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=nLUin7Lz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736915322; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SiaIVXIhhM1sp+r10z/vJyY+tzDQMN+pj3uAuSz6ZII=; b=v4BCfZvIbFQhhT4z273UEJLL8klpwA7P5e8ZVijqBQ+xKSDHhVxFrJtsUzjzsEFU+ieUOV VcrGVuK5oBLf6MKIYbhSZhNPcfgfNOS+V7crjf2mAfHsCBMnKImHj2KFKavkCjYLEopZIY SP0ydn/rvreiMaE4elPUGUcUBbOp2r0= Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-4aff620b232so2108525137.0 for ; Tue, 14 Jan 2025 20:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736915322; x=1737520122; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SiaIVXIhhM1sp+r10z/vJyY+tzDQMN+pj3uAuSz6ZII=; b=nLUin7LzJiztD0bQBKv9yQ/WUwVQP/vbXSYmMY1fUwM64szmopSskPfNMTXNGtUnKu sEoWZ0mQL2NVSHtYj8ucohrBAz/9KQeZg0Lp5wBtvIHO5hyWgDuwbPJhuNLDFuc4qeGt DYso8j3dYALwF72ZtmDX/gJGmuhoulsNHybg0fYHHqNf263ipfjBFiMiVBtYh2VkR6sr zBJtgerLy19YL3XN5EYseyJTZlgbpHdq29ABEI2d1VijwycnfP6ToaUo9b700tHi/OLW +QGQ3CwyJFgTk4DxyQD6TWfoImrqvS0HtQ5YPeUEcUDjIHx4XyQXF1MrPQy8mlUvtmHw BxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736915322; x=1737520122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SiaIVXIhhM1sp+r10z/vJyY+tzDQMN+pj3uAuSz6ZII=; b=jGxeIynFChC4qcZm9SvEaVxibZBIlU7pw7oPW8eE32b51K+R5ztlcCMt1KpkSnVxlr ZA1MF0fCgjkJc+w9gjpR+/u3tounm+xuILD1gUZ9G2lBrOgfAb95hwDEXlLwWnsq97ab Pe1JrOyjN/xzD1DaDdbkvYL3YVc5k9YDVVHNmss8wuEhxoETXCNThSh8SAmMX2Mg+v4x PXXdhkdQB+PnxDniUChtkyiV1993P8TpyaNxeRMIJAjGA2yhuhg6NFN3SLiebVo28FGy QC3tp85jEoSdtiR5WcUBmaxQcH2w7N+707SB8wiZHegWfBYhFYOL4NPtrTMGuausTcI0 TwQw== X-Forwarded-Encrypted: i=1; AJvYcCVqLrBYXa/G7UER7MPRcpkhhPFu3qsdVfzhRvvaMSxG2tzvwl7gESF4BZC97XrrUYV76tPa2hy+3g==@kvack.org X-Gm-Message-State: AOJu0YyeE/aHYpoqHJDiUOwEo5JetkrXk4qm63kiuOKFTxrFkmMODGwP jhshPc287A4xQIMMOrozvl2WIfjk21Nw45X9AEKJQ38t2NKRoHdcE3q1YTv2uDr6+9uZFaIv6t+ EdRvy6vM8btfFbt9MBBRBWV1TZwen9tSLQrsi X-Gm-Gg: ASbGncvrybJUCEWxI+c1A7az6VLUb0/oDM8sfQ4Dn5VU+/bWfUW7ozMhii0N64imdDQ CQDkbW/ztPvmpUndlRyVfM7v360nQWbCHvqivwNUYOTnRtv8aoNEmfV31zx4ibcJ2NyQg1oU= X-Google-Smtp-Source: AGHT+IH/FRwv1gjMQVdrZyTpxRo/2P7ZfMOmxND6HntPtKv8PRHbhPpC3eKReWiv2QbmErnwLgBIFI50EeMrfGttcP0= X-Received: by 2002:a05:6102:370f:b0:4b3:c658:2a36 with SMTP id ada2fe7eead31-4b3d0f8f840mr23231900137.8.1736915321756; Tue, 14 Jan 2025 20:28:41 -0800 (PST) MIME-Version: 1.0 References: <20250113093453.1932083-1-kirill.shutemov@linux.intel.com> <20250113093453.1932083-5-kirill.shutemov@linux.intel.com> In-Reply-To: From: Yu Zhao Date: Tue, 14 Jan 2025 21:28:05 -0700 X-Gm-Features: AbW1kvaBboGLsqdjopVloMA7j9dnfG52vbiddOAszVwHNFJf23o0CFxEnOZVFVU Message-ID: Subject: Re: [PATCH 4/8] mm/swap: Use PG_dropbehind instead of PG_reclaim To: Yosry Ahmed Cc: "Kirill A. Shutemov" , Andrew Morton , "Matthew Wilcox (Oracle)" , Jens Axboe , "Jason A. Donenfeld" , Andi Shyti , Chengming Zhou , Christian Brauner , Christophe Leroy , Dan Carpenter , David Airlie , David Hildenbrand , Hao Ge , Jani Nikula , Johannes Weiner , Joonas Lahtinen , Josef Bacik , Masami Hiramatsu , Mathieu Desnoyers , Miklos Szeredi , Nhat Pham , Oscar Salvador , Ran Xiaokai , Rodrigo Vivi , Simona Vetter , Steven Rostedt , Tvrtko Ursulin , Vlastimil Babka , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E000D16000F X-Stat-Signature: ftzg5nxp657dgpsj9she9goz8ks7wqox X-Rspam-User: X-HE-Tag: 1736915322-935550 X-HE-Meta: U2FsdGVkX198rdcfjatxXBYFmVNRJU2QXGeqf4jVU6sJBruzb8FqRwHLdE/Fr2Ib31zu+Af5Ui8rrCBTtpGfKCM1SkgBqGJ2zjyz/NauK/C2tnu/1Q+9g7wt2lqISfs4/R7/+DUyqyBxwdzpRyKiaTWPbTp1thvP1fg1CkRGsmjO3FMX49Wmhxh6BaZBR79SxpRcRKJv8LyND/kVGJo4RGtkcQV5qmhUH3Ufb1fClcYUlegfqEiyOrr1M1OsF/kMg+KofeQ3wuwAshIu1kGp85/I9mCJ3TLasUXHzyXK6etzr1vXnqIDEC8LmtHvghnKnYXTisYp+zYizLVrqAwcphXZJQUms860XPv52JhpAm+lXCVHsCIWUJfXJH2Ja9DhHUVdTTqKkaD7j5gXiIfdhQ6wmQGlDse33++uHRZ8ypzlz03Q6DWb0pIQcT84wgKejvdUjkTN+ILlQ8T5v8WqOLgA1sPjnDojyjpnOA5XYoQoE4ppTHW78OxvQeOEUhBfi6wZ8wiotWHyKLWZKDh5K3QCMr0/wCQ6CeoW689uW7+MlJ1Sj9zgoG/K6xHg3qpZWbv7ILkFWeB7FDRso6vMsUjbV7hnVwvlFNTyuuv5xmLByZ3zwYEKS7Mp3mJVVmqEFbqwauACxH940orFNxN7eQyIrjazPAx/ogYxx4On7ZUGw5HtxdA0PzrOGw3nwBi2TqrL/ztwISoJ4YWWe+m+2fLoGMVvYcu6yK4Ympdy1f0aDNVfB975A4XPUqSNDBlTbEYpR452DAZTs0cA7GZNjFZlCrdqvqElMVqXwlDSvAyHgwATz/45cIi/gGsBc9DNpyGQmcwmKAuPtZh0sSkIqXpOdUUku+c0kz6ZEhOmcdx0IjwwQA4a5cELdEytTDi0HMb8lam+DE6/wndZ4W+/1uMpVJKnyxaH2q3pBG7aEqTgyz6xYyBb98XJUkGUIOm6xTmM1G5D7sKNOdePp85 jZv1SzvH t+NtyuxcGGjHop/lFwMICmmJ1lF4tuPRZ4EXG+cExvQWtdROi4bEWGht+x3ETKN+u3pMt/b3wr9w2jz9W9VpCnYvI+80G41tvgTZqwv1Rr4+W/e/+1Gvnn8qwETXH3kJEmp7MlbUpTx48KXTV1CE7PTwLFThqQa+O7cQotBCppwc7c2IBniarPEPWBnlG8Tw6zzqCv4OWTBq/z0oMFy7X47wWOysfamdK1lgoXvDoOtZl5Pv4todVk+X0T8t7KkfuaUxQB+JHgIzWBe6nvDB1qdzdYGT7e1booI7a X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 14, 2025 at 11:03=E2=80=AFAM Yosry Ahmed wrote: > > On Tue, Jan 14, 2025 at 12:12=E2=80=AFAM Kirill A. Shutemov > wrote: > > > > On Mon, Jan 13, 2025 at 08:17:20AM -0800, Yosry Ahmed wrote: > > > On Mon, Jan 13, 2025 at 1:35=E2=80=AFAM Kirill A. Shutemov > > > wrote: > > > > > > > > The recently introduced PG_dropbehind allows for freeing folios > > > > immediately after writeback. Unlike PG_reclaim, it does not need vm= scan > > > > to be involved to get the folio freed. > > > > > > > > Instead of using folio_set_reclaim(), use folio_set_dropbehind() in > > > > lru_deactivate_file(). > > > > > > > > Signed-off-by: Kirill A. Shutemov > > > > --- > > > > mm/swap.c | 8 +------- > > > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > > > > > diff --git a/mm/swap.c b/mm/swap.c > > > > index fc8281ef4241..4eb33b4804a8 100644 > > > > --- a/mm/swap.c > > > > +++ b/mm/swap.c > > > > @@ -562,14 +562,8 @@ static void lru_deactivate_file(struct lruvec = *lruvec, struct folio *folio) > > > > folio_clear_referenced(folio); > > > > > > > > if (folio_test_writeback(folio) || folio_test_dirty(folio))= { > > > > - /* > > > > - * Setting the reclaim flag could race with > > > > - * folio_end_writeback() and confuse readahead. Bu= t the > > > > - * race window is _really_ small and it's not a cr= itical > > > > - * problem. > > > > - */ > > > > lruvec_add_folio(lruvec, folio); > > > > - folio_set_reclaim(folio); > > > > + folio_set_dropbehind(folio); > > > > } else { > > > > /* > > > > * The folio's writeback ended while it was in the = batch. > > > > > > Now there's a difference in behavior here depending on whether or not > > > the folio is under writeback (or will be written back soon). If it is= , > > > we set PG_dropbehind to get it freed right after, but if writeback ha= s > > > already ended we put it on the tail of the LRU to be freed later. > > > > > > It's a bit counterintuitive to me that folios with pending writeback > > > get freed faster than folios that completed their writeback already. > > > Am I missing something? > > > > Yeah, it is strange. > > > > I think we can drop the writeback/dirty check. Set PG_dropbehind and pu= t > > the page on the tail of LRU unconditionally. The check was required to > > avoid confusion with PG_readahead. > > > > Comment above the function is not valid anymore. > > My read is that we don't put dirty/writeback folios at the tail of the > LRU because they cannot be freed immediately and we want to give them > time to be written back before reclaim reaches them. So I don't think > we want to change that and always put the pages at the tail. > > > > > But the folio that is still dirty under writeback will be freed faster = as > > we get rid of the folio just after writeback is done while clean page c= an > > dangle on LRU for a while. > > Yeah if we reuse PG_dropbehind then we cannot avoid > folio_end_writeback() freeing the folio faster than clean ones. > > > > > I don't think we have any convenient place to free clean dropbehind pag= e > > other than shrink_folio_list(). Or do we? > > Not sure tbh. FWIW I am not saying it's necessarily a bad thing to > free dirty/writeback folios before clean ones when deactivated, it's > just strange and a behavioral change from today that I wanted to point > out. Perhaps that's the best we can do for now. > > > > > Looking at shrink_folio_list(), I think we need to bypass page demotion > > for PG_dropbehind pages. I agree with Yosry. I don't think lru_deactivate_file() is still needed -- it was needed only because when truncation fails to free a dirty/writeback folio, page reclaim can do that quickly. For other conditions that mapping_evict_folio() returns 0, there isn't much page reclaim can do, and those conditions are not deactivate_file_folio() and lru_deactivate_file()'s intentions. So the following should be enough, and it's a lot cleaner : diff --git a/mm/truncate.c b/mm/truncate.c index e2e115adfbc5..12d2aa608517 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -486,7 +486,7 @@ unsigned long mapping_try_invalidate(struct address_space *mapping, * of interest and try to speed up its reclaim. */ if (!ret) { - deactivate_file_folio(folio); + folio_set_dropbehind(folio) /* Likely in the lru cache of a remote CPU = */ if (nr_failed) (*nr_failed)++; Then we can drop deactivate_file_folio() and lru_deactivate_file().