Perhaps rename m to ma now ?

I am curious, why ? If we allocated something, why not validate the pages despite we cannot validate the whole suggested run ? The caller accepts the cost of the read for all pages, why don't we read as much as we can get the memory ?

Purely stylistic note. I believe it would be easier to read if you used switch (req) there. The initial if() in vm_page_alloc() always caused the headache for me.

Since you copy the function body, you can also change this.

I did that, though I forgot to update the comment above. Did you mean in vnode_pager_generic_getpages()?

Are you suggesting moving the partially allocated pages to the correct pindexes, to avoid leaving a hole before ma[0]->pindex? If so, sure, I can add that.

I agree, I'll change it.

I mean, commit the rename in advance.

Yes, but this is a small consequence of the larger decision. Mostly, I do not see a reason to waste the done work to allocate.

I always imagined it would be better written by a switch that fetches the limit value and then a single comparison.

I have a change to make this an atomic which would be much better expressed that way if you don't mind doing so now it will make my patch simpler.

I'm not sure why it needed to move though?

Since we do not need compatibility with some previous iteration of vm_page_alloc_pages, can we just drop the _after? There will never be some non _after version of this api? I realize it keeps it consistent with vm_page_alloc_after() but there are other inconsistencies between the two so I'm not sure it matters?

feel free to ignore my naming suggestions if you don't like them.

Since there is nothing to do in an else clause can we shortern with reserv() && extend() as the other functions do.

Quite a lot of this code is duplicated among page alloc functions. Can we make some inlines to avoid this?

Can't we bump the wire count once? It's a minor optimization now that they're per-cpu but on some archs it still has to disable critical.

Is this right given that you haven't bumped the wire count for these pages yet? This looks like you're doing the full teardown for pages that haven't been initialized? Am I misreading?

Rather than LELVEL_0_NPAGES this should be min(VM_LEVEL_0_NPAGES - index, *countp)

Nothing seems to be using the return value other than a zero check?

Ok.

Sure, but I think this is largely inconsequential - partial allocations will only happen during a severe memory shortage, and overall system performance is quite degraded by that point. So I don't think it's very important to try and optimize for that case.

However, it's easy enough loop over the partially allocated range and perform:

vm_page_remove(m);
vm_page_xbusy(m);
vm_page_insert(m, <new pindex>);

so I will do that instead.

I was on the fence about this. I don't see why it's inconceivable that we might someday want a wrapper that looks up mpred?

Yeah, I messed this part up. It's clearly untested at this point. Will fix.

Ok, but this doesn't affect correctness unless I'm missing something.

vm_page_alloc_pages_domain_after() stores the return value in "avail".

I'm not sure how to do it cleanly. When initializing a run of pages, it's nice to pre-compute various page fields (oflags, etc.). So ideally we'd have a function which initializes a run of pages. But alloc_contig returns an array of struct vm_page, while alloc_pages returns an array of struct vm_page *.