On 2026-03-07 at 03:16 +1100, "David Hildenbrand (Arm)" <[email protected]> wrote... > On 2/2/26 12:36, Jordan Niethe wrote: > > Introduction > > ------------ > > > > The existing design of device private memory imposes limitations which > > render it non functional for certain systems and configurations where > > the physical address space is limited. > > > > Limited available address space > > ------------------------------- > > > > Device private memory is implemented by first reserving a region of the > > physical address space. This is a problem. The physical address space is > > not a resource that is directly under the kernel's control. Availability > > of suitable physical address space is constrained by the underlying > > hardware and firmware and may not always be available. > > > > Device private memory assumes that it will be able to reserve a device > > memory sized chunk of physical address space. However, there is nothing > > guaranteeing that this will succeed, and there a number of factors that > > increase the likelihood of failure. We need to consider what else may > > exist in the physical address space. It is observed that certain VM > > configurations place very large PCI windows immediately after RAM. Large > > enough that there is no physical address space available at all for > > device private memory. This is more likely to occur on 43 bit physical > > width systems which have less physical address space. > > > > The fundamental issue is the physical address space is not a resource > > the kernel can rely on being to allocate from at will. > > > > New implementation > > ------------------ > > > > This series changes device private memory so that it does not require > > allocation of physical address space and these problems are avoided. > > Instead of using the physical address space, we introduce a "device > > private address space" and allocate from there. > > > > 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. Instead of a > > PFN, device private pages use an offset into this device private address > > space to look up device private struct pages. > > > > The problem that then needs to be addressed is how to avoid confusing > > these device private offsets with PFNs. It is the limited usage > > of the device private pages themselves which make this possible. A > > device private page is only used for userspace mappings, we do not need > > to be concerned with them being used within the mm more broadly. This > > means that the only way that the core kernel looks up these pages is via > > the page table, where their PTE already indicates if they refer to a > > device private page via their swap type, e.g. SWP_DEVICE_WRITE. We can > > use this information to determine if the PTE contains a PFN which should > > be looked up in the page map, or a device private offset which should be > > looked up elsewhere. > > > > This applies when we are creating PTE entries for device private pages - > > because they have their own type there are already must be handled > > separately, so it is a small step to convert them to a device private > > PFN now too. > > > > The first part of the series updates callers where device private > > offsets might now be encountered to track this extra state. > > > > The last patch contains the bulk of the work where we change how we > > convert between device private pages to device private offsets and then > > use a new interface for allocating device private pages without the need > > for reserving physical address space. > > > > By removing the device private pages from the physical address space, > > this series 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 now went through all of the patches (skimming a bit over some parts > that need splitting or rework).
Thanks David for taking the time to do a thorough review. I will let Jordan respond to most of the comments but wanted to add some of my own as I helped with the initial idea. > In general, a noble goal and a reasonable approach. > > But I get the sense that we are just hacking in yet another zone-device > thing. This series certainly makes core-mm more complicated. I provided > some inputs on how to make some things less hacky, and will provide > further input as you move forward. I disagree - this isn't hacking in another/new zone-device thing it is cleaning up/reworking a pre-existing zone-device thing (DEVICE_PRIVATE pages). My initial hope was it wouldn't actually involve too much churn on the core-mm side. It seems that didn't work quite as well as hoped as there are a few places in core-mm where we use raw pfns without actually accessing them rather than using the page/folio. Notably page_vma_mapped in patch 5. But overall this is about replacing pfn_to_page()/page_to_pfn() with device-private specific variants, as callers *must* already know when they are dealing with a device-private pfn and treat it specially today (whether explicitly or implicitly). Callers/callees already can't just treat a device-private pfn normally as accessing the pfn will cause machine checks and the associated page is a zone-device page so doesn't behave like a normal struct page. > We really have to minimize the impact, otherwise we'll just keep > breaking stuff all the time when we forget a single test for > device-private pages in one magical path. As noted above this is already the case - all paths whether explicitly or implicitly (or just fogotten ... hard to tell) need to consider device-private pages and possibly treat them differently. Even today some magical path that somehow gets a device-private pfn/page and tries to use it as a normal page/pfn will probably break as they don't actually correspond to physical addresses that actually exist and the struct pages are special. So any core-mm churn is really just making this more explicit, but this series doesn't add any new requirements. My bigger aim here is to use this as a stepping stone to removing device-private pages as they just contain a bunch of redundant information from a device driver perspective that introduces a lot of metadata management overhead. > I am not 100% sure how much the additional tests for device-private > pages all over the place will cost us. At least it can get compiled out, > but most distros will just always have it compiled in. I didn't notice too many extra checks outside of the migration entry path. But if perf is a concern there I think we could move those checks to device-private specific paths. From memory Jordan did this more as a convenience. Will go look a bit deeper for any other checks we might have added. - Alistair > -- > Cheers, > > David
