Re: [PATCH v2 00/11] Remove device private pages from physical address space

[Alistair Popple <apopple@nvidia.com>]

On 2026-01-08 at 07:06 +1100, Andrew Morton <akpm@linux-foundation.org> wrote...
> On Wed,  7 Jan 2026 20:18:12 +1100 Jordan Niethe <jniethe@nvidia.com> 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.
> 
> Welcome to Linux MM.  That's a heck of an opening salvo ;)
> 
> > Needing allocation of physical address space has some problems:
> > 
> >   1) There may be insufficient physical address space to represent the
> >      device memory. KASLR reducing the physical address space and VM
> >      configurations with limited physical address space increase the
> >      likelihood of hitting this especially as device memory increases. This
> >      has been observed to prevent device private from being initialized.  
> > 
> >   2) Attempting to add the device private pages to the linear map at
> >      addresses beyond the actual physical memory causes issues on
> >      architectures like aarch64  - meaning the feature does not work there [0].
> 
> Can you better help us understand the seriousness of these problems? 
> How much are our users really hurting from this?

Hopefully the rest of the thread helps address this.

> > Seeking opinions on using the mpfns like this or if a new type would be
> > preferred.
> 
> Whose opinions?  IOW, can you suggest who you'd like to see review this
> work?

I was going to see if I could find Lorenzo on IRC as I think it would be good to
get his opinion on the softleaf changes. And probably Felix's (and my) opinion
for the mpfn changes (I don't think Intel currently uses DEVICE_COHERENT which
this bit has the biggest impact on).

> > 
> > * NOTE: I will need help in testing the driver changes *
> > 
> 
> Again, please name names ;)  I'm not afraid to prod.

As noted in the other thread Intel Xe and AMD GPU are the biggest. Matthew has
already offered to help test Intel (thanks!) and Felix saw the v1 posting so
hoping he can help with testing there.

> I'm reluctant to add this to mm.git's development/testing branches at
> this time.  Your advice on when you think we're ready for that step
> would be valuable, thanks.

Will leave the readiness call to Jordan, but we were hoping to get
this in for the v6.20 merge window if at all possible. I realise
we're probably running late given we generally like to let stuff
settle in development/testing branches for a while prior to the
merge window, but it did have an early round of review last year
(https://lore.kernel.org/linux-mm/20251128044146.80050-1-jniethe@nvidia.com/)
and I reviewed it internally and it looked very reasonable.

I will take a look at this latest version later today.

 - Alistair