On 3/17/26 02:47, Alistair Popple wrote: > 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.
... and there is quite some. stuff like make_readable_exclusive_migration_entry_from_page() must be reworked. Maybe after some reworks it will no longer look like a hack. Right now it does. > > 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. Yes. I provided ideas on how to minimize the impact. Again, maybe if done right it will be okay-ish. It will likely still be error prone, but I have no idea how on earth we could possible catch reliably for an "unsigned long" pfn whether it is a PFN (it's right there in the name ...) or something completely different. We don't want another pfn_t, it would be too much churn to convert most of MM. > > 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. Well, so far a PFN is a PFN, and when you actually have a *page* (after pfn_to_page() etc) you can just test for these cases. The page is actually sufficient to make a decision. With a PFN you have to carry auxiliary information. > > So any core-mm churn is really just making this more explicit, but this series > doesn't add any new requirements. Again, maybe it can be done in a better way. I did not enjoy some of the code changes I was reading. > > 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. I meant in stuff like page_vma_mapped. Probably not the hottest path, and maybe the impact can be reduced by reworking it. -- Cheers, David
