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). > > > > * 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/[email protected]/) and I reviewed it internally and it looked very reasonable. I will take a look at this latest version later today. - Alistair
