If we allocate KVA from the system, isn't it safe to assume that it is already unmapped? Are we making that assumption elsewhere?

If we're swapping in a stack, I think we can assume that all of the pages are invalid.

I think it might be some kind of leftover from previous code for caching.

Do we have a way to assert that the address is unmapped in KVA ? I cannot think of any.

swapout unwires the pages, everything else is up to the pagedaemon. If pagedaemon did not reused the page, then it can be still valid.

Can't we just call pmap_kextract() on each page in the guard page range and assert that the return value is 0?

Thanks, somehow I missed that case.

This might as well be defined as OBJT_SWAP.

Given the defined size of the object the second argument should be "atop(ks - VM_MIN_KERNEL_ADDRESS) + i"

WAITFAIL is to get back to the pref domain? This seems like it will be incredibly rare. Is it even worth handling?

The overload of kstack policy is a bit odd but I guess that's the only way to do it at this layer.

At first I did not bother, but it is not really much extra work. It is probably rare in general, but if we are swapping out kernel stacks, swapins might be happening concurrently with a memory shortage.

I agree that specifying the policy this way is kind of awkward, I just didn't see a nicer way to do it.

Ideally vm_page_grab_pages() would try to ensure that the request is satisfied by contiguous pages, but we don't yet have a good way of specifying that. Reservations don't help here because of the guard page. The individual page allocations will go to the per-CPU caches, which don't do a good job of returning contiguous memory. In practice, with plenty of free memory we do end up with many contiguous stacks, but small amounts of fragmentation are common, e.g.:

0x8a2a95000: vnode
0x8a2a96000: anonymous
0x8a2a97000: kernel-stack
0x8a2a98000: vnode
0x8a2a99000: kernel-stack
0x8a2a9a000: vnode
0x8a2a9b000: kernel-stack
0x8a2a9c000: kernel-stack
0x8a2a9d000: vnode
0x8a2a9e000: vnode
0x8a2a9f000: anonymous
0x8a2aa0000: kernel-stack

D14376 added a function that would be of use in this scenario.

It's not really correct to say that reservations don't help, it's just that they would never become fully populated.

I think reservations could be used if we introduce a layer of indirection in the stackaddr->obj pindex mapping. Rather than using atop(stackaddr) as the pindex, we could use a unr allocator or a vmem arena or whatever to allocate virtual indices within kstack_object. The virtual index for a stack mapped at a would be PHYS_TO_VM_PAGE(pmap_kextract(a))->pindex / kstack_pages. Then there would be no holes in the pindex space, so the use of reservations for kstack_object wouldn't suffer from the problem above. This works especially well when kstack_pages is a power of 2, which it is by default.