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 E8E441DFF0 for ; Fri, 28 Nov 2025 15:09:46 +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=1764342590; cv=none; b=QxNAj7lKbE0aN04vgdggDokJyGrqgGeA0m4JFav3D2I1DqHDqF4R2yIMg+SJ4pD+tiCpOZ6f6PDa7uC6jEKj7jH+iuLUT6sZLJfApHFU7jYOwvXv74HV9Xm8aulUIPddXI7wyVZE6R9EVnpAnffTQIwwkXc2vHHgx80cPKB5HwM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764342590; c=relaxed/simple; bh=7YWBhk6Qk1f809+0cDxxE8VBX+SyZPECA0CBhDM2uQ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rxCPSF7LjL2XFqfUufzHZevv+71EmGkSMIYqC+k6Lyx+5ccFoNTf0dZzR9VU7n8ljeXk+zCdtlpe5tEi1G6f7q8heVj3GIS6zZ+NQ/JCu/9oWDIMKqpxZwa05FqtQ8XQCTFWXLSWGcYdf+n/04bNE9cDv06SDe1/pMoECD8OWVU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=nAZtPLjV; 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=none 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="nAZtPLjV" 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=deXTwbDIKs9JQLaQPnholrd8uRGRoXWWQE0vJWC870s=; b=nAZtPLjV8PFjQDFEYcBUeJl4cx sUhx+y7Yk8L6G787cH2nx2wVLFyNpxdWD0ERiN3dK4tFZR2wgSyEnW5gitBxk/69XNE2pLbLR9gJZ rhDhKLd3shzKnQZRZ7uu7huJUVTwBVM80/EErs4R38LJ2Q0WSkV1pBxoBsKRZQxCr1cqE680IZ7Dt oEQwqfo3ScvTk5SBwsKUNAr8kHCYIMqmQ4YYYbpruVX9FfzGoJyGFf5YxUeBLjt3qM6xYWhdcBjxb YI/7cNQQfbE7NF9MfemZQ5+EQeZKRYVjkJzsYUvRe4zMoytWH46VhJ9vfUbs1eiJLETqo4U9Co47E 6ZbLcNSA==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vP06Q-0000000DM7x-0Atr; Fri, 28 Nov 2025 15:09:42 +0000 Date: Fri, 28 Nov 2025 15:09:41 +0000 From: Matthew Wilcox To: Jordan Niethe Cc: linux-mm@kvack.org, balbirs@nvidia.com, matthew.brost@intel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, david@redhat.com, ziy@nvidia.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com, lyude@redhat.com, dakr@kernel.org, airlied@gmail.com, simona@ffwll.ch, rcampbell@nvidia.com, mpenttil@redhat.com, jgg@nvidia.com Subject: Re: [RFC PATCH 0/6] Remove device private pages from physical address space Message-ID: References: <20251128044146.80050-1-jniethe@nvidia.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=us-ascii Content-Disposition: inline In-Reply-To: <20251128044146.80050-1-jniethe@nvidia.com> On Fri, Nov 28, 2025 at 03:41:40PM +1100, Jordan Niethe wrote: > A consequence of placing the device private pages outside of the > physical address space is that they no longer have a PFN. However, it is > still necessary to be able to look up a corresponding device private > page from a device private PTE entry, which means that we still require > some way to index into this device private address space. This leads to > the idea of a device private PFN. This is like a PFN but instead of Don't call it a "device private PFN". That's going to lead to confusion. Device private index? Device memory index? > By removing the device private pages from the physical address space, > this RFC also opens up the possibility to moving away from tracking > device private memory using struct pages in the future. This is > desirable as on systems with large amounts of memory these device > private struct pages use a signifiant amount of memory and take a > significant amount of time to initialize. I did tell Jerome he was making a huge mistake with his design, but he forced it in anyway.