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 F05AFE77188 for ; Tue, 14 Jan 2025 18:03:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83D84280017; Tue, 14 Jan 2025 13:03:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EDAC28000C; Tue, 14 Jan 2025 13:03:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68DAC280017; Tue, 14 Jan 2025 13:03:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4C77228000C for ; Tue, 14 Jan 2025 13:03:39 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0587A80BFA for ; Tue, 14 Jan 2025 18:03:38 +0000 (UTC) X-FDA: 83006830116.25.3B0B1A5 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf22.hostedemail.com (Postfix) with ESMTP id 1D708C0006 for ; Tue, 14 Jan 2025 18:03:36 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CznRktmp; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736877817; 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=jCDM3nH5nsddwHhx2RaJOUmEIWUcGJSFM1b2iKFUASA=; b=NXxd9HssW3ZKzxvQMuZB7hiwFPP0SgBRz7gWLgYBnph8KusW48R3SevZToX4FhwIMTNoyE /lwxnjHir8hsgvwZ+b0YaPizDZ7nkSxtB2s1iry+2WsSn9BdAmZTEWAoaLXlhfPUNSlgsB 2CWc4UfGaxXgmnEaS9t8ApaN8tSQ97s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736877817; a=rsa-sha256; cv=none; b=uN4DF8bkgzgKnf68HYip9auLxEl2tKhcjHfDzMXiv7Njb/qiUA/FuPh0AS+xyI9QyVQma2 T6mXjZcrmLkZGD2zJQ31B52a3xYy7R3mKEg6HDrU69FF356dqcN44jkPFNHOWaPPODdRSp UxCM5QuNECkEOjlIpiG5vk1v8DtQu24= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CznRktmp; spf=pass (imf22.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6dcc42b5e30so68547506d6.1 for ; Tue, 14 Jan 2025 10:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736877816; x=1737482616; 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=jCDM3nH5nsddwHhx2RaJOUmEIWUcGJSFM1b2iKFUASA=; b=CznRktmpHMiRbZN+PtoteUqwatrF+D4vzdPqwNkGKMNAXvUHR/G/KjoR37UzoQoYCY QMzr3EPuF3TEEESen3kVvS3Ew44I1XYBytTtE+8GL2cMKxXiQnH3Rg1szJNAO7zkDJwT vCe0D2w1P5cSBdhW6cJL1W94TiIQaMUujwNpta7gbPdft4qU323WjFDWTjV24tDCM59I OSh7c/8ww2p9HZ+KM8xT3Dlf2pAhH5jhvM2m7tkjw6P9oEPgUImODB7Pf2htzosGBXLX 20zYjHU7MyH1Gzv6+l0sUWP8Ko1RvhF2gv7Q5TX0hDWpvyZ96ELAHkWe5yXKdYatL3wh 2Skg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736877816; x=1737482616; 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=jCDM3nH5nsddwHhx2RaJOUmEIWUcGJSFM1b2iKFUASA=; b=S41z1iMiudL2lFhT4fIPZGUqZe2JEuIXAzXxWMzEf+lZh/4cWaGCW95VtudlV6FNhV ThUbITaoc2U8nn9O6V4pZjp9K6HMLEafxE4VvcPpFC1toHctMMXZhs0+25fnTvh5LSGP nRSJ3/i5Y7nNilyYHZlpXQpCxUjTSaFM0edloUWqQwnpy8W/ZGKGV8ly4h7EZJwfjiz/ VZ+nW+1TD1JXw099nmgy1J6RPjmVof6JSCPMTVLQvSwB/5vxdjKeE0tGqtOFnmxOZGBs tTku9Dvezk7Eed6/AXkO8ObC9+1BnmZ5zWA4LIt/8aIHcWg9gQ+I6O/k4CaeBn8np+U+ A4eg== X-Forwarded-Encrypted: i=1; AJvYcCW7sgJKV9B/XRZKy7bjoy9cuFbSAF8ZKqoG8KzF2aS3Gp8S31Ahvhh+jjlQcOlKKesdGjWZV9XYnA==@kvack.org X-Gm-Message-State: AOJu0YyZRQnz5chht0HuYHi5jLk5sDNazcYcpL+N66nA1Pi99Eg1i4hU 77CMHwsP19m7vY9Wj4cPRYliSwV0Wa2lCC1PvgXraaC9Ni2njlQ95DJK/QzgoFODjORfwVlOQ5c NfLDpQhmWJR3OMHvFGYDZP6BZZt/376AF0vYm X-Gm-Gg: ASbGncsqjmiFsvRVwsKkLXERx0JNQ3uxj77gJHrCqn4U1gc1T5ZZ1NsAJs0z8Legaa+ HH7QA21Gx9zEIlrFTvwmbIfY5QeehpolCaTjEvLJAXTAOGhUiRb3i0YWyzibCIk1s5BWt X-Google-Smtp-Source: AGHT+IFGbuWEbA/VXL6JtTCiH5khxzq5smFlxJG6dJ+DoVw7dHdiOta9Wy11BiH/OhRxCrhzSnn1aPsUJ6zkleOgF28= X-Received: by 2002:a05:6214:4002:b0:6d8:b3a7:75ba with SMTP id 6a1803df08f44-6df9b333a5bmr404226066d6.45.1736877814969; Tue, 14 Jan 2025 10:03:34 -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: Yosry Ahmed Date: Tue, 14 Jan 2025 10:02:58 -0800 X-Gm-Features: AbW1kva-gyu4zE6Wcq68qpyyzNdu3annXYt-FkuQBdGnmZoPJXjoi47oGp9e6C0 Message-ID: Subject: Re: [PATCH 4/8] mm/swap: Use PG_dropbehind instead of PG_reclaim To: "Kirill A. Shutemov" Cc: 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 , Yu Zhao , 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: rspam10 X-Rspamd-Queue-Id: 1D708C0006 X-Stat-Signature: o8jy17kagerkkqrpox55uyd6tj9duu7q X-Rspam-User: X-HE-Tag: 1736877816-777611 X-HE-Meta: U2FsdGVkX1//pN/m9doEGq1fwpYNDFy3GTMTQSU2lx9eOBSYSyFU5gMVNTbLc1O3v4hmyPC6PgXrf1xh5Ov3QcLS3h5QBJhOoKfc5KmK0yJPR1Vn8UB1HsRvrgFjHjHnxBCT2zIQhLPTGzNoOBnL4BjufQSCxMOjZf0WiYvN5H6PKWySL0358Mj1j/DNeabku2q5LxNrtxBOtiydbJYE+mPU8EZnOqMbcvp5SCrV3Bo78cgOcpdbFKZe7DsnbrmPudawqIIDLurRvEckBRnyIwE5e2s747WsA1EznPxzIxABg3YhR8xuQnnMLiEXJtR8hrb4bPZa4aKEJwLAhn4KPH/gJuafK2fKY+l130ZYqFcEd1xSQZxVL/7S0jk25pMtZVotPkSgDcMS/FTcpOsek37FERSINiUUwp3TKRPEfvVqF2B3i8jfMDUF7l6BBj6Jb7toHwdTr04GsWqRExjuurh8BJmU1Zm54ACLK0v5blJXsz+MDtr4PFd9/1S+LWcVMiAEPqJRvaW9hjd4/EUbDVOjOMURl/wzLze6nJLxaJjXxZG8V4h5FpBxQFYYnelWqRQ0RgjkCuvwgzo/VgsTqxD78SyduICrf+GUS2huG9l3cjQXWPaYImE1HjYxflpicABT3vIbGEyknICFg3awGZ3qQH5e5su0l7ci1ESJN4Z+GZb/wFLEGGhgtU13R82vzpBGLcqNAXLAZ9i7H9SQzVYXNihOLR53ug/BlkoCxtmVqiAfJBRZOM1Xbxn8fKY9uhS+jxWV5ZRon+LbpSsd+sAYmTpB/odocUzv0nowWlDlq3l0MWCRIAgfW7qTnhVkm9/70OMJSq+hqIHXnH7DC+WVsnHhz3p4LOy9/vkX41r/iPPK6wxGyoTvEcHhD5xE3KnOJhAfY91vo3rXClSfv7varjyFLoGdgFngeoFZDho+6phfxn3UbfaxHavzQxMl7C8yDoqwm92pbec7zg8 9Fs6BEbg Bqe8KCNGXSFLndZPibJPUvXa5IlPh8Hu5Oz/92iRdk6VMrwcAlXh3R3qeA8Jo6rTRGoCMOmEjcZPO4CEA8HGwy8vJcKWLN0Fpxu6wKDkm2FJrsZHeL2805w0iPiE5R8SYNlaZx+rm2GvNsGM6SA0VMzjfWFVl1xmzABeS1d9aY1ykxPBgkySVaMTNajE7QMUxOefEoQQLleFH6K4auHu7glE0QtDsUYIex4D5jXGS4HCBsGae5D1zoGgB4+rKkOS2EMTFfCtQOxMIWxmXduSjmi4gEh4xnixk8JCHA5nD3SRd56I= 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 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 vmsc= an > > > 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 *l= ruvec, 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. But = the > > > - * race window is _really_ small and it's not a crit= ical > > > - * 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 ba= tch. > > > > 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 has > > 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 put > 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 can > 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 page > 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. > > -- > Kiryl Shutsemau / Kirill A. Shutemov