From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 917A93176E0 for ; Thu, 9 Apr 2026 02:07:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775700467; cv=none; b=IMLpVqPlx6Z/4qIwAD6t0VovqrBeJR0RE55dElQD3lbsiVyUqARZPDIEKFrzBcQnJbgo33bwQjXZefjY6BTJCcKnBi6w93ZesOGw1/a4EtPmi0SNsHzYCpH8i437rNJmy/lgfEYHWo9wnZVVNx+7JZKYiWMkaBdqqgLGwvtS8Kg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775700467; c=relaxed/simple; bh=f+BvsdXCelqVPu1ZTii6+3t7WeF9lW4AmeZ0lcGbNM4=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Ldl1KljGl/jJoXpEZYe+PDndDFfpo0q0VHgUvwfFjZ6vumgyQlzCCZjydztpfUNG28vMGW5FzOz0e46RfoCGY6oxGQTyhPwdFenHS92qFoTyT0cWkzrRjcWQtpbwWTKLdYfbaewbTkUITehJu3WlQ6EVsqW7heXY2ixSL8Bs2jE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=eJOGiaka; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="eJOGiaka" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8988FC19421; Thu, 9 Apr 2026 02:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1775700466; bh=f+BvsdXCelqVPu1ZTii6+3t7WeF9lW4AmeZ0lcGbNM4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eJOGiakaGP9bFmnUhNDXoJ5WHtDM8DNU3thdhKpYCHTNePFYo+WbI7ute6MoV0Wz1 GgKeSn6Etk3si2QyCLnYknLPsgrIoXHDlEc+A4pZaa2tdeHUy9HruM4MmMOFmJhGEh +uSKdrmqrofCbwM4+Kf2/BP0VxbH/zxDxB5snep0= Date: Wed, 8 Apr 2026 19:07:45 -0700 From: Andrew Morton To: John Hubbard Cc: David Hildenbrand , Jason Gunthorpe , Peter Xu , Mike Rapoport , LKML , linux-mm@kvack.org, Sourab Gupta Subject: Re: [PATCH] mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios Message-Id: <20260408190745.40f0c0231a475e697c970fd4@linux-foundation.org> In-Reply-To: <20260409014647.397515-1-jhubbard@nvidia.com> References: <20260409014647.397515-1-jhubbard@nvidia.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 8 Apr 2026 18:46:47 -0700 John Hubbard wrote: > Since commit f002882ca369 ("mm: merge folio_is_secretmem() and > folio_fast_pin_allowed() into gup_fast_folio_allowed()"), > gup_fast_folio_allowed() falls back to the slow path for any order-0 > folio with a NULL mapping when CONFIG_SECRETMEM=y. This causes a > performance regression for drivers that allocate pages with alloc_page() > and insert them into VMAs via vm_insert_page(). These pages legitimately > have a NULL folio->mapping, but they cannot be secretmem pages. How significant is the slowdown? > Secretmem pages are always added to the secretmem inode's page cache via > filemap_add_folio(), which sets folio->mapping to the inode's i_mapping. > A folio with a NULL mapping can never be a secretmem folio. The > NULL-mapping check was intended to handle truncated file-backed pages (a > reject_file_backed concern), not secretmem detection. > > When only check_secretmem is true (and reject_file_backed is false), a > NULL mapping is sufficient to prove the folio is not secretmem, so the > fast path can proceed.