vm: Micro-optimize page rename

[alc]

Summary

Rename vm_page_rename() to vm_page_iter_rename() to reflect its reimplementation using iterators, and pass the page to this function rather than spending clock cycles looking it up. Change its return value from 0/1 to a bool.

[dougm]

Comments in vm_reserv.c need to be updated to reflect this change.

If you have measured the improvement, how big is it?

[markj]

sys/vm/vm_page.c

2072

Perhaps further clarify that failure happens only when memory allocation fails. In particular, if a page already exists at the destination, we panic.

I'd also clarify that the page is passed directly only as an optimization.

2093

I believe we can strengthen this to KASSERT((m->ref_count & VPRC_OBJREF) != 0, as in vm_page_insert_radixdone() for example.

[dougm]

sys/vm/vm_object.c

1793

Fix comment.

[alc]

sys/vm/vm_page.c

2072

I didn't describe passing the page as being an optimization as I'm afraid that doing so could be misinterpreted as meaning that NULL can be passed.

[alc]

Update in response to reviewer comments.

[dougm]

sys/vm/vm_page.c

2075

I don't see a panic anywhere.

sys/vm/vm_reserv.c

681

'm' and 'new_object' are now the second and third arguments to vm_page_iter_rename, so you should be either less precise ("vm_page_iter_rename(...)") or more accurate ("vm_page_iter_rename(&old_pages, m, new_object. ...)").

[alc]

In D47829#1090358, @dougm wrote:

Comments in vm_reserv.c need to be updated to reflect this change.

If you have measured the improvement, how big is it?

The conversion to iterators made vm_object_collapse_scan() and vm_object_split() slower by 14% and 5-6%, respectively. This change eliminates about half of that slowdown in each case.

[alc]

Update in response to reviewer comments.

[alc]

sys/vm/vm_page.c

2075

vm_radix_insert_lookup_lt() panics.