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 CE8E8C54FB3 for ; Thu, 29 May 2025 15:03:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B1CF6B007B; Thu, 29 May 2025 11:03:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 362766B0085; Thu, 29 May 2025 11:03:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 279346B0088; Thu, 29 May 2025 11:03:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 09BAC6B007B for ; Thu, 29 May 2025 11:03:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 12DDBBC62F for ; Thu, 29 May 2025 15:03:04 +0000 (UTC) X-FDA: 83496263088.06.FB61836 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 0C7471C000F for ; Thu, 29 May 2025 15:03:00 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xux1uokl; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748530982; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=gBCtzCBuKebhbkVKW/WxOd0hxWSVky5kkX/lrbQSWnM=; b=inG6HbNFeKUt22j5pczkTEUvhXmmbClLrm6vqMO/eBvDu0sx5rW73h9jsNbIGa7WZBD+Dv XwrT9pVJNqDlZuNCGbcY/T5W20t5Y5Qf3fwqv+r2H3obb4BvjTmhyJttmWbd95jRl4jZ6e meoQygi9jmcia/Au/yDfNtuChhHSffI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xux1uokl; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748530982; a=rsa-sha256; cv=none; b=VhNdpAPTnxXw17h96npwLrB/Us1Clsd3tpQKY9eTsqBR1K76nheZym54c4lOqMIOk0FcW4 JDlE3HscZrtPso2ULwrMoLn4nqws67Jgw/8TTofOpb05LADndddr4fcvkeYLDjDQATWJTn 74EfjB1kGsoVViRoDHrFZzD1lScyFz8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=gBCtzCBuKebhbkVKW/WxOd0hxWSVky5kkX/lrbQSWnM=; b=Xux1uoklnVrn6LKavIK1p8IulI 8upw0NnX3D65sMy3Y+CLGahuIQFzR7d9KO8XZfPDgzYpzeHbsOw3Bg+X1EZkdfrcrU2NhcIACiI/5 m8U2+bcNd5ey6pEr97zMIxFE91ugO8INk49oteiFr6U05msWOkYA1zpGphEStlvc9QfY70Wu4C3C1 fwpj4SPjfShOwY3aEzcxlasFhlGuakGXogvW/osf/BZmXs0hsvwNTj1fsqZd5PwRa9en7BxW1A/Gd 5pWn0lxBqIfx3C2lzwIe6T1rUDogW94Fp+hsXs9nK6IVPbh4GHCvuiukANYRdpY0JvGJbkIJ4UFMB aSL7wePg==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uKemX-0000000ErUk-08AZ for linux-mm@kvack.org; Thu, 29 May 2025 15:02:57 +0000 Date: Thu, 29 May 2025 16:02:56 +0100 From: Matthew Wilcox To: linux-mm@kvack.org Subject: How should we RCU-free folios? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0C7471C000F X-Stat-Signature: eci9nm3jzijpbijn4jpxwfw5kpnu46y1 X-Rspam-User: X-HE-Tag: 1748530980-46753 X-HE-Meta: U2FsdGVkX191kYZJ/lMfBszDyVcw0M5HrJE38VF/zjzhYMZ7u5rE1ngvDmHVzXsVIgUwGQ4JAJg+L34pE8q+CicMLvZSW8HeOuzrO0hxtxCfhpCapYs44KnNqZg+eRA2J9Z/MY956PMTQgP+x3lB/S5ua5srYpOrnyqupbCDUTF41qzL8GHOwXwzBkWgs5Lpwpy/HqXP4VU15EVUmn3bhtcAcDXRsJMipqpMcYSt3distOk4zepiISud0rHeyxxwi17C+EtU6nFBWjMiUCy4Rit/Q0CeP8LTPC8dhoqT6x4PlAdL60CeNHFH8qMWUKZ0zSGhQKEhH11ft0XWjy56gCOIdwto8qpwxg9/f8TAjajukvk/IwbkQDyvpZ+Da9+7WFoTka2VaSY/DldmcltLwOAQXc3CGiG+FGHE3hIKcR1SeMDQFPxaQYJgn8pWIaO95Kd7t0QTOlKtYcSpLzfGhKqMQ0VODXJ7nkGgGeNvN+LsldjFKMm7yAVRxhzMF+j3dKRBNDuRDuPRhWK/O9OFnQ7y7EK9cBj8/Yy13JRCmHCzrvJZGRgL9tXJ5X4fAVN80ejFGCIF8OZzKgdNlQTAEBrYU1vPvXzsC9jl81ajRlBGPTE3baxHnWcVJuoViA8m6mYt7LugqzNbxioKqBONH/SEfwW8+d8KZDrgSiAbLAbPZEwPE+x++RAw/826qe5cqJxqWsgimVX3F+y3PpejyOqg/JItsRV7qKmeax0HOXG9waFwHkU+Q/ZrBlW6s3uZ43c0yfgRTlnsJEqhPZ48ysznS3Cpip3u0U4JMAqjsZ7VgXgKIWc+joBcM4r2na7c3ZFZGuKlz4EG7c3qso2EJc3RMAEx7jwHJCbsW46SCHrT0v0AUV7FciW5QPp7LmUKzE2xxN0RG1yCbrGfEy3fkas9B8YAy4eG0WLBWuFFWnPrjftUSamlwYH8o0wpArea3ADYOwOQ7X7Ac/3+hQt A8H1ysns fQFpMPZozzNQGavR7lTzrDk0hnvg1sEOXPo0HPupAqD+7cCDshMTm5VYz/7+xeiWzO64I9EovmR5Et6PQfOW3oB6uTryIvQXXj0Jn0vRO2K1xxEHEK3lgonwcrwPgwyIS2Bg0RU/WCxL76becNxYYXze3jQoM/t2ATK5kBCn846pcpLn0mLLR6iyDzuTLK4gE7Nk1jEPTeV7NCo7udq77h0YLOYnl4Xta1UB9+H0G96OltvA4Jc03GcwNpxziBIsC1GsXJPMXbhlS19ofDoOg2ESYcbC6sG6vnXNF0Ib69XldE/07j12QcHAGkpcK+BYyE+lJEO9HX1SPXyY= 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: When folios are allocated separately from the underlying pages they represent, they must also be freed. See https://kernelnewbies.org/MatthewWilcox/FolioAlloc Since we want to do lockless lookups of folios in the page cache and GUP, we must RCU free the folios somehow. As I see it, we have three options: 1. Free the folio back to the slab immediately, and mark the slab as TYPESAFE_BY_RCU. That means that the folio may get reallocated at any time, but it must always remain a folio (until an RCU grace period has passed and then the entire slab may be reallocated to a different purpose). Lookups will do: a. Get a pointer to the folio b. Tryget a refcount on the folio c. If it succeeds, re-check the folio is still the one we want (If pagecache, check the xarray still points to the folio; if GUP, check the page still points to the folio) 2. RCU-free the folio. The folio will not be reallocated until the reader drops the RCU read lock. The read side still needs to tryget the folio refcount. However, if it succeeds, it does not need to re-check the pointer to the folio as the folio cannot have been freed. The downside is that folios will hang around in the system for longer before being reallocated, and this may be an unacceptable increase in memory usage. 3. RCU free the folio and RCU free the memory it controls. Now an RCU-protected lookup doesn't need to bump the refcount; if it found the pointer, it knows the memory cannot be freed. I think this is a step too far and would I'm favouring option 1; it's what we currently do. But I wanted to give people a chance to chime in and tell me my tradeoffs are wrong. Or propose a fourth option.