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 B95C925C6EE for ; Fri, 28 Nov 2025 07:41:00 +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=1764315660; cv=none; b=ZJc4OtTXnpV1GqUvWpIOM+YEIUepYZ7IHrBHeD/x1tsbOqkINFZpRiNxrCvTJiav986DxlDFSZ9FWHqJ2JmEK4FWY1oUPfFEpCu/+74ddE6ukjXPxwvwIhwvf0qRYw4T/xGH9OoADHPyUp1As2SsjsHFHhkOoDxPFgy3vl6CvxU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764315660; c=relaxed/simple; bh=Cvm8VHYmiklHkHLbjGWk9H4wF4lDIswUe+zfGMLAC5w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JyrhgaNmkKmCQ0gSdGLNIy/MwMStff8cBVGL61EFLSqOi/wwYMv0S6FTjNJcClqtAGxlG8hb/NEQ3QEeuDzgPiu23xf1ZIEnbed+JHL7x15dfyW0tNjE5sRvw51U8Jc8xCrF9NLwUMJLd0QkupGlFH1KfgEkcfGyUEsnWC855+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U1hC56Z8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U1hC56Z8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D189C4CEF1; Fri, 28 Nov 2025 07:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764315660; bh=Cvm8VHYmiklHkHLbjGWk9H4wF4lDIswUe+zfGMLAC5w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=U1hC56Z8WBw8QH9tGIQdeGelW13iXtcQtuL4XpwBwmjePCPQhrTCZIVKhN2ciLq3r f8GZLBRJBtNo9UGCkcA8iqQXFe6o+v18dbZ8bqh0r0TPSpAq8qLjsLbBnDr2KsXr31 YL3TpqC9WksHalFF8G4sFNkk8LDWGWifJtIpBKqi1fmicyoUSxAC71X+F90J9EGvEE rQoLXnL03j4L93SDlDU414+zNo5p1iNk3ifG32eTPkjKI2FMdsCvaUkxpIsI/tREV6 BIQ1ZnxT8LVOdT9VUVAdbMLjuXGmeaeLNq9vzUZDexsGe4zSSZqKWjzq+iSBLXxkD9 r2Kg1RkU7ZkFA== Message-ID: <301376ee-3439-4d3e-a2c9-8604e7bf49fb@kernel.org> Date: Fri, 28 Nov 2025 08:40:53 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/6] Remove device private pages from physical address space To: Jordan Niethe , linux-mm@kvack.org Cc: balbirs@nvidia.com, matthew.brost@intel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, 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, willy@infradead.org References: <20251128044146.80050-1-jniethe@nvidia.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251128044146.80050-1-jniethe@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/28/25 05:41, Jordan Niethe wrote: > Today, when creating these device private struct pages, the first step > is to use request_free_mem_region() to get a range of physical address > space large enough to represent the devices memory. This allocated > physical address range is then remapped as device private memory using > memremap_pages. Just a note that as we are finishing the old release and are about to start the merge window (+ there is Thanksgiving), expect few replies to non-urgent stuff in the next weeks. Having that said, the proposal is interesting. I recall that Alistair and Jason recently discussed removing the need of dealing with PFNs completely for device-private. Is that the result of these discussions? -- Cheers David