Address @alc 's comments.
The bump allocator state was moved to struct vm_domain.
I was not entirely sure where to place the nofreeq struct within struct vm_domain, so please let me know if you think there's a better position w.r.t. cache usage.

Address @alc 's and @markj 's comments:

In D45163#1032283, @kib wrote:

What if you revert the order of allocation, first finding some domain which provides enough physical pages to back the stack, and then try to allocate KVA from corresponding arena?

In D45863#1048057, @alc wrote:

Here is the amd64 pmap change:

Address @alc 's and @mjg 's comments.

Address @alc 's and @markj 's comments.

In D45863#1045744, @mjg wrote:

did fragmentation drop though?

Thanks, your answers clear things up! I had an incomplete overview of the issue, I see now that its best too keep VM_FREEPOOL_DIRECT.

In D45046#1044547, @markj wrote:

Reading this and the related patches, I am a bit uncertain as to why this code needs to live in the vm_reserv layer. From my reading, UMA's small page allocator is effectively using this code to maintain a list of 2MB allocations from which we draw slab allocations; a separate list is used to segregate slabs for UMA_ZONE_NOFREE zones.

What problems does this vm_reserv extension solve? I can see that this will segregate NOFREE slabs, which is a good thing, but we don't need to modify the vm_reserv layer for that; UMA could easily maintain a linked list of 2MB chunks from which NOFREE slabs are allocated. Once a chunk is exhausted, try to allocate a new one and put it at the head of the list, otherwise fall back to regular 4KB slab allocations. The NOFREE case is simple and doesn't need a lot of machinery.

Address @kib 's comments.

In D45046#1038011, @bnovkov wrote:

I spent some time evaluating this patch with four different metrics (thanks @markj for the first two):

• Number of reservations with at least one NOFREE page
• Number of reservations with at least one UMA slab, excluding NOFREE slabs
• vm.pde.promotions
• vm.pde.mappings

Regenerate diff.

I spent some time evaluating this patch with four different metrics (thanks @markj for the first two):

• Number of reservations with at least one NOFREE page
• Number of reservations with at least one UMA slab, excluding NOFREE slabs
• vm.pde.promotions
• vm.pde.mappings

Update vm_reserv_uma_small_alloc to retry if someone else filled up a partial reservation.

In D45368#1034980, @rlibby wrote:

What about arc_available_memory() in sys/contrib/openzfs/module/os/freebsd/zfs/arc_os.c? Isn't that still broken?

Looks good!

Address @kib 's comment - unmanaged reservations are now distinguished using an invalid vm_object value instead of a separate variable.

Update patch.

Update patch and summary.

Reworked patch and updated summary.

Address multiple comments:

• enabled UMA_MD_SMALL_ALLOC unconditionally
• removed redundant include guard in ppc uma_machdep
• removed obsolete u_int8_t types

In D45163#1030231, @mjg wrote:

why even support something like this?

instead, if pages can't be all be allocated from one domain, the code could be patched to free up whatever it did and try a different one

Remove redundant m == NULL check.

Simplify vm_thread_stack_back page allocation loop.

Add missing arm vmparam.h updates.

Removed stray UMA code from diff.

Address @markj 's comment - uma_small_alloc code deduplication was carved out into a separate revision.

In D45045#1027214, @kib wrote:

Why not M_NOFREE?

M_NOFREE was already taken by sys/mbuf.h, M_NEVERFREED is one of the alternative names proposed by @alc .

Address @mhorne 's and @kib 's comments:

As promised, I've removed some redundant bits from the patch, it should be a bit clearer now.

Regenerate and simplify patch.

Address @markj 's comments and fix a couple of issues:

• Certain kstack KVA chunks were released back to the parent arena with improper alignment, causing vmem_xfree to panic
• swapping in thread kstacks triggered a panic as the former code relied on vm_page_grab_pages

Sorry for the delay, @markj reported a panic when booting this patch on a NUMA machine and it took me a while to set up a NUMA environment and properly fix the issue.