Hi,
On 8/1/26 12:49, Alistair Popple wrote:
On 2026-01-08 at 07:06 +1100, Andrew Morton <[email protected]> wrote...
On Wed, 7 Jan 2026 20:18:12 +1100 Jordan Niethe <[email protected]> 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).
It also effects intel's driver because the mpfn changes also touch
migrate_device_pfns() which gets used there.
So also looking for Matthew's thoughts here as well as Felix's.
* 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.
Yes, I should also be able to get run this through the intel-xe CI.
The other area that needs testing is the powerpc ultravisor.
(+cc) Madhavan Srinivasan - are you able to help here?
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/[email protected]/)
and I reviewed it internally and it looked very reasonable.
Matt has kindly said that he is reviewing the patches so will wait for
his feedback.
I'd also like to get the results from the intel-xe CI first.
Andrew, I'll advise on including in mm.git after these steps - but I don't
expect any major issues at this stage. The changes have been solid with the
hmm selftests and with updating our out of tree driver to use the new
interface.
Thanks,
Jordan.
I will take a look at this latest version later today.
- Alistair
