Hi, On 2020/02/25 21:38, Nick Hudson wrote:> On 25/02/2020 11:24, Rin Okuyama wrote:
On 2020/02/24 9:29, Rin Okuyama wrote:__HAVE_CPU_UAREA_ROUTINES is enabled for alpha, mips, powerpc/{oae,ibm4xx,booke}, and riscv. I investigated whether it is really necessary or not for these archs (except for riscv). In short, most of these archs do *not* need direct-mapped physically contiguous u-area for now, as far as I can see (source code reading and experiment on powerpc/oea, just experiment on other archs). Only the exception is powerpc/ibm4xx, which should also be fixed. So is it time to retire __HAVE_CPU_UAREA_ROUTINES?Oops, mips64 depends on direct-mapped u-area (with UPAGES == 1); KASSERT fires on ERLITE (MIPS64_OCTEON) if __HAVE_CPU_UAREA_ROUTINES is turned off:On mips64 iirc it's architecturally defined to have direct-map, i.e. XKPHYS, so the fallback from cpu_uarea_alloc to uvm_km_alloc "should" never happen. This conditional is also slightly off I think http://src.illumos.org/source/xref/netbsd-src/sys/uvm/uvm_glue.c#247 247 while (USPACE == PAGE_SIZE && USPACE_ALIGN == 0) { the following is more correct (imo) while (USPACE == PAGE_SIZE && (USPACE_ALIGN == 0 || USPACE_ALIGN == PAGE_SIZE)) { All that said I'm facing my own issues with uvm_pglistalloc not waiting for > PAGE_SIZE physically contiguous allocations (2 pages in my case)
Yeah, I think you are correct. Memory allocated in this loop is page
itself, and therefore page-aligned. With this change, as well as
similar one in uarea_poolpage_free(),
https://nxr.netbsd.org/xref/src/sys/uvm/uvm_glue.c#277
277 if (USPACE == PAGE_SIZE && USPACE_ALIGN == 0) {
--->
if (USPACE == PAGE_SIZE &&
(USPACE_ALIGN == 0 || USPACE_ALIGN == PAGE_SIZE)) {
kernel on mips64eb works fine without __HAVE_CPU_UAREA_ROUTINES.
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?
Thanks,
rin