From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 7B7A54570E9 for ; Fri, 7 Aug 2026 22:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786140034; cv=none; b=n65X5df7FBOtziXjsPgxH5XjwOAKxwgBV3Lbf6zZhxsDe5cYUlUZ1DSkvO3VVay6CQO9hB6MEunqGjRjXMrKxZHl3IMgTFjiUTboPtjPY4+JnhPQjtwChZYYgtVHcrrK12MVUdbsHY20Z/GxCJ/+BTeoMEkD31wqRUyf8vBZoyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786140034; c=relaxed/simple; bh=SHuqDs2YhRiO3Z1hnYWl0HUS4OmB+hEB0HjcqoTIzIA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gqXtNO55vfA1sx1pyUw/FcXGiUGvnR7tG4y1OkpuLb6YL2UMO/tKaFoj8icKd71fbazjDENrDAi/Vs4k2s+0SawugRvlngVG6mPCXXUITKrF/uo9Fh1NR3mQsefVncOh3DBDlHvrOvgVwikIRpz9UUcyQIbIIcxdFsqD9gTuMKE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=l3LIcieJ; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="l3LIcieJ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rMyxG+nPHVxHJ1KM+yO+RxpMBhOYpRjh117VjJdqmNU=; b=l3LIcieJ6AXIOCMvvamI+rcA+a XujTAm6DKG3jXmHB+i3ylb9K6h+eYDeuyBYQ8pdC9TyfSKe3/rQXPgufJoCS0XWnne2iyslYPuZWn 8TwuuMIaHNN+Osyife+4g8Oxsg8MUYkhViFfmcKps9AQ6CAMEJFJpI8p6D8FXRlNQ02O9FcDUSqoc 0i6zF64R3JZ/iLxFdjb5laolsf3/ZxcYu2+TJ1MokpuXDnzlQStpTNwiBo2mZy6KGcChSvgmBx78O 1dZLZVllADx/9PPwhvG4yYS0ADp6KtOncFpy8OvY8bEsf8AhBDtrJXDDGUgvsgG11oDXVLKqzanCk 208+cZOw==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wsPsK-0000000Dbim-3pzX; Fri, 07 Aug 2026 19:05:00 +0000 Date: Fri, 7 Aug 2026 20:05:00 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: Tal Zussman , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Christoph Hellwig , Yosry Ahmed , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/6] mm/swap: rename __swap_writepage() to __swap_writeout() Message-ID: References: <20260806-b4-page_io-folios-v1-0-0899bac3b826@columbia.edu> <20260806-b4-page_io-folios-v1-6-0899bac3b826@columbia.edu> 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: On Fri, Aug 07, 2026 at 01:01:08PM -0400, Johannes Weiner wrote: > On Thu, Aug 06, 2026 at 06:55:38PM -0400, Tal Zussman wrote: > > Commit 84798514db50 ("mm: Remove swap_writepage() and > > shmem_writepage()") renamed swap_writepage() to swap_writeout(). Rename > > __swap_writepage(), which operates on a folio, to match its caller. > > Update a stale reference to swap_writepage() in swapfile.c as well. > > > > Signed-off-by: Tal Zussman > > Looking at that commit, I can only guess that pageout() had an > influence on the swap_writeout() name. > > However, on the read side of the page_io.c API, we're following > swap_read_folio* consistently. > > [__]swap_write_folio* would seem more symmetrical? I wanted to be sure that filesystem authors see this as something unusual rather than something they should implement as a counterpart to their read_folio operation. So it was intentionally asymmetric. I'm open to discussion of better names, but my hope is that we get closer to the 'do direct IO' model and shmem doesn't need to swizzle its folios into the swapcache to get them into the swap system. > [ At the risk of starting something, should the file itself be > renamed? swap_rw.c or swap_io.c or something. ] I'm not opposed to that either!