Normalize VM_ALLOC_ZERO handling in page busy routines.

[jeff]

Summary

grab, grab_pages, and grab_valid all have slightly different ZERO semantics. The next three patches resolve that. grab() did not set the page to valid if zero was passed in. Making this change allows me to simplify and improve the vm_page.c internal busy logic so there is less redundancy. I reviewed all callers. pmap uses it but does not care if the page is valid. Other grab users intentionally set the page valid after.

Making this change allows me to handle the zeroing and wiring in vm_page_grab_release() so it is identical to all implementations which are all using this convenience function. It simplifies the upgrade to and downgrade from exclusive so that we can zero and set valid.

Test Plan

stress2

[markj]

sys/vm/vm_page.c

4269

This is stale now. Maybe, "Helper routine for grab functions to finalize page state before returning."

4289

Why do we do this outside the block above? PG_ZERO will only be set if the page is freshly allocated and VM_ALLOC_ZERO was requested.

Note that there is nothing synchronizing this update in general. In practice it is ok because in the scenario above we will be holding the object lock.

[jeff]

I think there may be a bug in this. busy_sleep may not properly wait for an exclusive lock if it is sleeping to zero a page while it is sbusy and the caller requested an sbusy after zeroing. Currently no caller does this so it is not going to cause problems. There are simply too many flags and it complicates things but I do not see an easy way to drop many.

sys/vm/vm_page.c

4289

We are not actually guaranteed to have the object lock. We are guaranteed to have an exclusive busy in the block above. Let me look more closely at flags and think about this.