On 2020/02/26 23:32, Jason Thorpe wrote:
On Feb 26, 2020, at 6:17 AM, Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote: So, all ports including mips64 do not need CPU_UAREA_ROUTINES anymore, as far as I can see. Can we try turning off __HAVE_CPU_UAREA_ROUTINES to see what happens, or should we be more careful?Platforms never "needed" __HAVE_CPU_UAREA_ROUTINES ... we didn't always have them. I think we should keep them ... they are a useful optimization when they can do their work effectively. However, we need to ensure that when they can't meet their constraints that the fallback still works.
Certainly. Then, what should we do?
Until now, we've learned:
(1) uarea_poolpage_alloc() can fall back into uvm_km_alloc():
https://nxr.netbsd.org/xref/src/sys/uvm/uvm_glue.c#269
This does not work if low-level routines need physically
contiguous (i.e., direct-mapped) pages for u-area.
(2) However, all ports with __HAVE_CPU_UAREA_ROUTINES actually do
*not* need contiguous u-area anymore, as far as we can see.
(3) Unfortunately, (2) does not mean that fallback of (1) is safe.
If some ports, that need direct-mapped u-area, bump USPACE from
1 to 2 (or more), fallback of uvm_km_alloc() results in memory
corruption. This is what we observed on powerpc/ibm4xx.
So, we have some options to do:
(a) Add MD flag to forbid fallback of uvm_km_alloc().
Or if this seems too much,
(b) Leave some comments in uarea_poolpage_alloc().
Thoughts?
Thanks,
rin