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 B8A82C02183 for ; Tue, 14 Jan 2025 08:31:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE7516B0085; Tue, 14 Jan 2025 03:30:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7053280001; Tue, 14 Jan 2025 03:30:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE9896B0089; Tue, 14 Jan 2025 03:30:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A038F6B0085 for ; Tue, 14 Jan 2025 03:30:59 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 275E11607A5 for ; Tue, 14 Jan 2025 08:30:59 +0000 (UTC) X-FDA: 83005387038.10.6804A6A Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf26.hostedemail.com (Postfix) with ESMTP id 65207140010 for ; Tue, 14 Jan 2025 08:30:56 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bPpe8rLB; spf=none (imf26.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736843457; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9E+LZiLS8fFa3YQ96Fm4Bxnm93B9hkucbYR6zH2UIzU=; b=drnOXVhp2MIkI2yx7udIHI2gFx6Kvu7eqDEtwyElLOV+5IrT4DvC5geZz3mI+802mICuzi UF12GDEl1NtRbtIQ9cN+dMZTY0wPXfpP8pbbWVG/4SjknxrqsEyLwadN8qGLukDL1iEkCX HBBKvP6BMQIFxlf1plSVHVLzV4o/h7M= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bPpe8rLB; spf=none (imf26.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.18) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736843457; a=rsa-sha256; cv=none; b=57/NDVJ3g0pzsxBXRtpnFNFEUKGqi7kUxoga2wClSzZJSJsC37p05m7BgxBz468gbPqqZZ gI4HhXmUQ8vChwiTZO/IlloBKl56EyLZlWhyNaoKKKUca3fbg9PvN+P0hH56O8pt5P7ZB4 4tOfxcaCIaC6yXBxCmP6ebXou0yeiwM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1736843456; x=1768379456; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=d76ZuYXYGd5MhYXwKrUOaL/NFOW9yG6blep811EcGeg=; b=bPpe8rLBGWo+iwEA6nH+LHKyctsoiA1awntTTW8+ozf2+ttlfPopd7+Y xYa6zuoLEsZWF+YYUtie5tnJ6Vle1wflDAN2v9owlTJBleP1F0ceOt73T 3w5d6hSF3ikWAzYKmMHLCuiWRYF7JWxRfY9Ekig4w0c5abO0BTxoqw+ZZ 1BR/x7iWoQVkdt3hmDQ/BwP2cRd+sNyCSVDg+k/cwYvbZxpDypUtGoC1o xoUNT2tiCrQk3P93NlldrDOPoSU5+bpxsYUAMFdyd25QmUDZ/QM+hGhhq NzmhrmamKnfMb7t/OkuJBrhwqBSTzvecmzZ+S+ORl/6u3mEchmkEPjzXF Q==; X-CSE-ConnectionGUID: LK5qIn03Ru61bAN/3C6t0A== X-CSE-MsgGUID: vfK7OdaKR8mX1bIDIOO/xA== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="37241828" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="37241828" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2025 00:30:54 -0800 X-CSE-ConnectionGUID: OGS8UdzDSvmjat/Rleu/Tg== X-CSE-MsgGUID: Yr9g/hOpTTeh7GM4krWnuQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="109880457" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa005.jf.intel.com with ESMTP; 14 Jan 2025 00:30:47 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id B879339C; Tue, 14 Jan 2025 10:30:45 +0200 (EET) Date: Tue, 14 Jan 2025 10:30:45 +0200 From: "Kirill A. Shutemov" To: Matthew Wilcox Cc: Andrew Morton , 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 , Yosry Ahmed , 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 Subject: Re: [PATCH 8/8] mm: Remove PG_reclaim Message-ID: References: <20250113093453.1932083-1-kirill.shutemov@linux.intel.com> <20250113093453.1932083-9-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Stat-Signature: 7e5xr81y8ks87uqm6bkqotzg34iz4uck X-Rspamd-Queue-Id: 65207140010 X-Rspam-User: X-HE-Tag: 1736843456-450276 X-HE-Meta: U2FsdGVkX1/bq9/I9tiUjqclB9j0LnY7jYblaOVXXsTzyNloZ2h7A/mMiFPmIBUZPnFROyNox3G3L86+iTurMjpKgcqIV+2qDfpZem78f6hcahZMCe2TUILN6jvItrnlU3FUIN/NKwyTFO+hl69zyGl5jQuH61wpR2K1zMqGDnvHgyPhkFMD//8vHF70KLOAkEQ371ON/49pCYzaTCuG70ue8cxqRDvhvGBCAthB9dGYgbg5gNSoR36bY12FxO3d79x5mHKYhWoh6Bdbt06Lg4J26C3a/lWH1xcxdZiidw2iHWf0Cu3LN5VBN41pCpVDxH1ar464XQSFv5LqO8eXxulU4cMynvipzHmDRyJEowy4rwpbDuvjrmQlQ7coioE9MRG5KCDBp+OW1IvjBWxKz3/g1/EIxnW8sI3FYc8mHtuotfDWjBseFXVOmxWjzq+LncVZO1MHDTFL5hdNBoJcy6FGjPhEhaBi/SAPYtdlaPhlTEr9WhKcdEYmE5opcvCR1dI3rg3olr8gZz7soBqjVUJFB/j5LrO+Tz8NftEQPpL3aAR8lB0Za24D2YU38rXfA5mmHu2Ad/sjqMEdrf0o05g5ebUgBQ/sxe88iLzLBBg1/qt4Y3q0XUyEjzNJBG6KtD+lBIBt2OA1KbBYtbR+bfkKa/h9zXMl0IvIrTdiyZEcJfuxr0Gwt0lDjsNd2uyS5+X8crPaSTRAO5MljwulExpQQeHshLHbl5udz4gi0/a1wT6+Uv+uQjSkEQ9upfjniiCo2qWtSgPoz4kfcgzsFhNyUlrCzOkrDESpaV2lcRhs6omV5UP1kgmHJkxQL0UnLi8Jn0CIXUgIkJcv2dgTL16RjQ5G+mN4iGMa/HguwGPNtNxlD8FHeVIhaI41gub6lEb6QhgxiH4eT969ZNa4OKvNoetpRjw/isTng5Lvnn9jj1BV21wU/pw2iRaRVLQoTJuNWa+bwGDGmdnoriL 2Sq92b1/ uQEqPANrT5I9y/5gcuked2bLEFFFkmgITn75mzZLyg1NNXLQeKHTrZV5i/VJiX3oeu4K5DaXj8s9/kpX5eQ55PO7L4fnIOXmoU1ypQSbcOOoG0UIyy6pXsbg+upl7xYYMMXMAyIRz8vFhTqqfg8NV3+nVUKVXsRyWEd/mpzMapCcW5jk/X+98c4w631qeNbfYOrZHzxo9EEVQeU/bzTq3guogle9ri2r1FqNSQQnLGjXOrBc= 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 Mon, Jan 13, 2025 at 03:28:43PM +0000, Matthew Wilcox wrote: > On Mon, Jan 13, 2025 at 11:34:53AM +0200, Kirill A. Shutemov wrote: > > diff --git a/mm/migrate.c b/mm/migrate.c > > index caadbe393aa2..beba72da5e33 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -686,6 +686,8 @@ void folio_migrate_flags(struct folio *newfolio, struct folio *folio) > > folio_set_young(newfolio); > > if (folio_test_idle(folio)) > > folio_set_idle(newfolio); > > + if (folio_test_readahead(folio)) > > + folio_set_readahead(newfolio); > > > > folio_migrate_refs(newfolio, folio); > > /* > > Not a problem with this patch ... but aren't we missing a > test_dropbehind / set_dropbehind pair in this function? Or are we > prohibited from migrating a folio with the dropbehind flag set > somewhere? Hm. Good catch. We might want to drop clean dropbehind pages instead migrating them. But I am not sure about dirty ones. With slow backing storage it might be better for the system to migrate them instead of keeping them in the old place for potentially long time. Any opinions? > > +++ b/mm/swap.c > > @@ -221,22 +221,6 @@ static void lru_move_tail(struct lruvec *lruvec, struct folio *folio) > > __count_vm_events(PGROTATED, folio_nr_pages(folio)); > > } > > > > -/* > > - * Writeback is about to end against a folio which has been marked for > > - * immediate reclaim. If it still appears to be reclaimable, move it > > - * to the tail of the inactive list. > > - * > > - * folio_rotate_reclaimable() must disable IRQs, to prevent nasty races. > > - */ > > -void folio_rotate_reclaimable(struct folio *folio) > > -{ > > - if (folio_test_locked(folio) || folio_test_dirty(folio) || > > - folio_test_unevictable(folio)) > > - return; > > - > > - folio_batch_add_and_move(folio, lru_move_tail, true); > > -} > > I think this is the last caller of lru_move_tail(), which means we can > get rid of fbatches->lru_move_tail and the local_lock that protects it. > Or did I miss something? I see lru_move_tail() being used by lru_add_drain_cpu(). -- Kiryl Shutsemau / Kirill A. Shutemov