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 1A286C36005 for ; Wed, 26 Mar 2025 02:21:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65EB5280050; Tue, 25 Mar 2025 22:21:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60EA4280048; Tue, 25 Mar 2025 22:21:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FE4C280050; Tue, 25 Mar 2025 22:21:42 -0400 (EDT) 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 32261280048 for ; Tue, 25 Mar 2025 22:21:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5CB78C158E for ; Wed, 26 Mar 2025 02:21:43 +0000 (UTC) X-FDA: 83262101286.22.E01C628 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 1F4712000C for ; Wed, 26 Mar 2025 02:21:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CDFEaSEH; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742955701; 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=H08voiyKqqmyqNnphcsyTXypKbCInKHul7dZLjLLGnI=; b=Cmrtvts5L3q5j0F+QGuYEqFg5IvwjBrSJqP9cjz8GxY/nwi43PnnGXOqW7euN3PYBp/wxa GWpU9xVKXEQf3JFAcUoq+PkTU6PXYy1m+2perYySlE8+rMpiTJWuFi8LpJjv03AVWrdhh1 yd5nhNKi4v6TT3iGDcs3LmidrpZGaHo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CDFEaSEH; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742955701; a=rsa-sha256; cv=none; b=d8shuxOIsL7IwqFLilUFplQ/kYSUmd54N2uxlTPXT7a23bpxcenzXv1ZuQ5iBBaWJPieUB oOM40sMP1jcB8+U/sslSznNgEmdQIyig9rXkN/efKnEBDjpGadETIx1k7922FudFQ+4pTg IOtp3IRTUBMMa2rHlxv/mDMAtLVZxvw= 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=H08voiyKqqmyqNnphcsyTXypKbCInKHul7dZLjLLGnI=; b=CDFEaSEHfoykny86NYKQKHmn5G 6WlxxkyLfovT6voel/lbboxcFnShvFmicZGU+i3BeaIwk+0EvREUPdYpRak50XMQE5wionOMtmxw0 IDDHfnb5InpdJ3oTTcO/HphPiAJIMg/Qzk8deokCg7sFFbfYHSPssaxIwU4/XJSwKq2Uy7vJOC/Bv 0X8ZiU4YaEXzROuulQSwCklU2Yvtf0zMDumCk1ruQU4w+O8rteYZ9BYWgT3yZgeSIfQ85ypPv2tWe LO3dXeTLon6UzJBDCTPIQH6p0KoDEq5q6f4V/g3eHHDDUfpDrAbL0RzUaypIgzGigu0P9vZPFvm1e lm3D9R0w==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1txGIF-0000000GLJh-2fck; Wed, 26 Mar 2025 02:15:51 +0000 Date: Wed, 26 Mar 2025 02:14:59 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: Alistair Popple , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 0/6] Allow file-backed or shared device private pages Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Stat-Signature: scx5qo5jnwkj9oqb4kzcfh9ffermnmd5 X-Rspam-User: X-Rspamd-Queue-Id: 1F4712000C X-HE-Tag: 1742955700-929791 X-HE-Meta: U2FsdGVkX19UGx4OKuS/XfBowGKfwHSXX/58381Ag28SkrN2SHehGwnXYWhyQzFlq6jKqCLaqLrnjLmv/AuvwKYCUZw5+KBz8c07b8CV89x7t20Z+0v6iFIEKPl87gWj/+RuRa/EOMgHHn5Mj9YCf1P9eWy3lHryU8TklXqY7ff8Z+oWkIKUyEBlrVo3HPQlL8Yu1OEXrnVempAMcrKT0c81w/0xWcc7SLYlO6GvG0LaQq86jLZHB3IWrjLxMtXgWc7ed78lcSZj3BoI4zQ0iIDqvNR3QFXV52AcinGKLCtW1P74QVbc31MiwjuEOiW9s4S/Pcn0zxMF3ijI2c5EARysYv8ccUWTaAy0htLNrpR4IsANhQReHqMx5ITG1ExsOAWmmGNAfHEd6O/9CFcZanAZJnfmAdGvxl50PjvvNZN9/nizSQw2JMIpOpK6kNCMVWug5ibXcpqmaM2mshjgxbzBJfTqPdPjPIS6UNA55Hj6lrdjEy4HSZug+OrLx5zifviqrqsB/pDKe0rwPbfFj3MdI7TSeM/Ra7ufnnQwh1/gCz0I/OWyuR5zxdeRZjTlHxzCC7TyiMuyOaQ0MFEG5HZ2/v+0kYsIqeU48xmO1k+cj8Dgl7pKvxJ6Vldyy0Hxkm417g1LNUQSPEHgyg+eVQetIXizNsdJnXU3vXqnEvWFuASuOvro6pMGjhinwhU7ku73zUf/NrFgRrBBgHPayC/gQ9xzb06Y1IwB4alyRYnuF9MtfYBVmir97fzwzKUDKgN0VDQoYu4ZsdaEqf1l2R8BFBBUHWR5COsniwCUjxEJxosMHFJisFuaS8CxXrpr2VInVhyX6keSENGK624AzPgrOW0r6C1gYMLwjNwm2ALixoUP4d1j+vtfxUzUE1ncYKu8PDZvd5cX+LcbmJ15ioSgWetongvh/cvcxz8K37srimDlFYvljML/ELs0A7fKxwruwghNbiI7XfuBM9s x35HKTff hdKnGtUs+fvKOqlME0jpTb8tFHhPFOmJxN1KoV6jFvz24KCG9sr3FaL89yK5heOEnlNodINHge5JwlwpG00acx26ZhkhBn8exTDG7ozdT7r2iMGrwkG64cNEJTtmnRzBeiFURGs1dMGMwyZhb1zTzbFKDWP73wwGmqsuaEP2mc1Ba3Lc4kMaEEyIlm3CWId36apoBia8+r/KUpUl7WPjghkZ1D/v+Vte+z7fu 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 Sun, Mar 16, 2025 at 11:04:07PM -0700, Christoph Hellwig wrote: > On Sun, Mar 16, 2025 at 03:29:23PM +1100, Alistair Popple wrote: > > This series lifts that restriction by allowing ZONE_DEVICE private pages to > > exist in the pagecache. > > You'd better provide a really good argument for why we'd even want > to do that. So far this cover letter fails to do that. Alistair and I discussed this during his session at LSFMM today. Here's what I think we agreed to. The use case is a file containing a potentially very large data set. Some phases of processing that data set are best done on the GPU, other phases on the CPU. We agreed that shared writable mmap was not actually needed (it might need to be supported for correctness, but it's not a performance requirement). So, there's no need to put DEVICE_PRIVATE pages in the page cache. Instead the GPU will take a copy of the page(s). We agreed that there will have to be some indication (probably a folio flag?) that the GPU has or may have a copy of (some of) the folio so that it can be invalidated if the page is removed due to truncation / eviction. Alistair, let me know if that's not what you think we agreed to ;-)