From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B75B47DFA2 for ; Wed, 3 Jun 2026 12:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780490467; cv=none; b=qf3z3RwTWNkicL4+F98+Pl6XGh+RUQgMujjSAvfsxN68bUYTRJf8BJPzX//PftRCBMZtUTYKfnfuR9hehJlJZZ+kkqsexWo9nuzDS5uPUNA0GURLaafnp90BWCOdV2kgaqk1p4i0tgY6ilFxS8BVUIh0ko3tHpC31A9hHmmvCac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780490467; c=relaxed/simple; bh=ENtubr53Kx85dmLhQ6TaEl2dHF72nooAhCBku3a9cdI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b3itfCgVEvcE4caSg8mjm3CaVTw5mnL4OKUhOpLiOLHojYUxDX9ePuCZnAMmp4SOpNTzXwZVgvBP+DujLrc8ptvBpLljr0y5U8qDuvOVZaDGoRsdyWZHbppbp9Y8CuLZHDcvBifMAElU5PAaLU+LrofKjN8esAFhF1AbbYPmjDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I7pyiEBS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I7pyiEBS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9D7C1F00893; Wed, 3 Jun 2026 12:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780490461; bh=AGwrdfa8qLYOzCYiYEBtpSv3/VKvDzE6dpVQrFCHUGU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=I7pyiEBSsv1qXzqFWZ1j+lm9f19zsfETib7kRZOKD6KyMC2Fehxe/pvG800JKwja/ RBMRd1Uv2JsJ37kLsOYyGScalYaE47SafqnVdazIm1I9cEezjd6dmL4f3H1oQwUKh+ 5jVdIQ9vyRrcX77GX1zGUC+bv4zhldDOUiXqG+aZfi1qpklKzd9fT172cYUCeK1rUq fLLUaqd2dzkV8VNecT31WnJcAk6excInWHEdWekLlZYsASRJwGKQR/Y36v6nPYKcmY 0u+Vt4sCqyvdrIbHJA2ZE07HrXIRM7lyDLDsYNIwht1f3fMFDr27VVHbdskcjaZqkg 6UPLDqyNIMPFg== Date: Wed, 3 Jun 2026 13:40:51 +0100 From: Lorenzo Stoakes To: Jianyue Wu Cc: Baoquan He , Matthew Wilcox , Tal Zussman , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Hugh Dickins , Baolin Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/3] mm: move folio LRU code out of swap Message-ID: References: <20260602-ch-swap-series-plus-folio-lru-cleanup-v3-0-5bbb567f8c99@gmail.com> <20260602-ch-swap-series-plus-folio-lru-cleanup-v3-2-5bbb567f8c99@gmail.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jun 03, 2026 at 08:29:44PM +0800, Jianyue Wu wrote: > On Wed, Jun 3, 2026 at 8:03 PM Lorenzo Stoakes wrote: > > > > On Wed, Jun 03, 2026 at 06:49:16PM +0800, Baoquan He wrote: > > > On 06/02/26 at 04:57pm, Matthew Wilcox wrote: > > > > On Tue, Jun 02, 2026 at 09:01:16AM +0800, Jianyue Wu wrote: > > > > > Rename mm/swap.c to mm/folio_lru.c so the filename better matches > > > > > the code's main responsibility. > > > > > > > > > > This keeps the implementation split from swap-specific code without > > > > > changing the published LRU helper interfaces. > > > > > > > > At the same time, we have Tal trying to split folio_wait.c out > > > > of filemap.c. https://lore.kernel.org/linux-mm/20260520-filemap-split-v1-0-c36ddc2b6cf2@columbia.edu/ > > > > > > > > I wonder if instead of folio_lru.c and folio_wait.c, we shouldn't simply > > > > have folio.c. Tal has 700 lines in his diffstat, you'll have about 1100 > > > > lines, so that's about 1800 llines which seems like a good size. > > > > There's some functions from mm/util.c that would fit nicely too -- > > > > folio_mapping(), folio_anon_vma(), folio_copy(), flush_dcache_folio() > > > > > > I think folio_lru.c and folio_wait.c are better than a single folio.c. > > > > > > A single folio.c with all of them would have no clear boundary for what > > > belongs there and what doesn't. For comparison, page_alloc.c isn't called > > > page.c (we have files called mm/page*.c). > > > > Well page_alloc.c doesn't only contain things that operate on struct page * > > right? > > > > Whereas folio.c is strictly operations literally performed on folios which seems > > like a good match to me. > > > > I find folio_lru.c and folio_wait.c far more difficult to figure out what goes > > where and there'll be a bunch of miscellaneous stuff all over the place. > > > > I vote for folio.c. > > > > > > > > > > > > > Other people have thoughts? > > > > > > > > Thanks, Lorenzo > > Thanks Matthew, Baoquan and Lorenzo for the naming discussion. > > I'm posting v4 shortly. It keeps the rename to mm/folio_lru.c so this > series stays a small cleanup on top of the swap_ops work. A broader > mm/folio.c (together with Tal's folio_wait split and the util.c > helpers Matthew mentioned) will be a separate follow-up > once there is maintainer consensus on the file boundaries. Agreed! :) Let's get this in first. > > Happy to help on that follow-up. Thanks! > > Thanks, > Best regards, > Jianyue Cheers, Lorenzo