> This is only the case if a real "larger physical page size" is = > available, of course, as opposed to simply clustering e.g. 4 4KiB = > physical pages into a 16KiB VM page. > > Another thing that would be interesting would be to bucket memory so = > that the allocator could easily request e.g. a large contiguous region, = > which would enable you to, for example, map all of libc's text with a = > single L2 PTE.
unfortunately, UVM has no good mechanism for dealing with large page sizes and AFAICT, netbsd only uses them for unmanaged mappings for kernels (and thus, is entirely MD in implementation and use), and we don't try to keep large-page sizes areas available so they're never going to exist after boot. early mapped libc.so probably would be OK but everything else sounds like a lot of work we haven't even planned out. .mrg.
