This needs a final round of testing before calling for more reviewers.

Apply reviewer suggestions.

Fix comment typo.

Apply reviewer suggestions.

After swp_pager_force_pagein, dont' rely on the local swap block value 'sb'. It may have been freed, so get a new one.

Combine the two last_timestamp updates into one.

Add necesssary updates to 'last_timestamp' in vm_map_wire_locked().

Correct handling of initial failures in map_wire_locked, map_unlock.

Change assertion from '<' to '<='.

Add more pip_wakeups.

vm_object_pip_wakeup() is now called.

Add vm_pager_page_unswapped() calls.

I'm guessing, with low confidence, that reducing the max block count to nsw_cluster_max would help.

Reinsert missing line.

Undo some changes that may not have been necessary and may have done harm.

In D20633#450353, @kib wrote:

vm_map_protect() is not the only user of the vm_map_clip_start(). More, I suspect that wire/unwire and vm_map_delete() might be more prominent users, because apps do not change protection often, while they definitely unmap enough. Did you evaluate these cases ?

Update after some changes that will reduce, if not eliminate, the need to simplify before clipping.

Accept reviewer suggestions.

This fixes everything I know of that was wrong before. It obviously deserves some robust testing.

I do think I've identified and removed the broken parts. I haven't fixed them and reinstalled them yet.

Fix vm_stack_locked by not modifying it. If I ever do modify it again, I should notice that new_entry is not the same as prev_entry->next until after vm_map_insert is called, which is a pretty big thing to have overlooked.

It broke boot, so I've reverted it. Now, while I look for the problem, I'll accept your shaming.

Fine-tune a comment that still includes "now will do cow".

Discard the parts of a comment that may mislead.

Apply reviewer suggestions.

Be more articulate.

Back-up one version.

Articulate.

Accept reviewer suggestion.

Don't over-simplify.

Accept reviewer advice.

Accept Kostik's suggestion.

Resolve a conflict.

Take Alan's suggestion.

Remove redundant test.

Retreat. I know I can improve something, and I know that I'm misunderstanding something else. I'll try to take the small win for now.

Move the simplification of entries to a separate, third loop, not because I want to but because I want to see if simplification is what's making my accounting assertion fail, or if the cause is some other thing I don't understand.

Add an assertion that the amount of swap space to reserved has been calculated correctly.

Remove a redundant condition, one which is tested for at the top of the loop.

If vm_map_entry_back is going to be invoked by clipping, then use the size of the untrimmed entry, which is what vm_map_entry_back will set as the size of the object that it creates. Otherwise, if there's no object, there won't be an object made and use the clipped map entry difference. Otherwise, use the size from the pre-existing object, the size of which won't be modified by vm_map_entry_charge_object, or by clip_start or clip_end.

Don't assume I can ignore ptoa(obj->size). Account for clipping when there's no object.

Address easy suggestions from reviewer.

Don't account for clipping in computing the amount of swap space to reserve. Fix some style glitches.

I understand that I violated a style(9) header rule too. Fix that.

Reorder events in the final loop now that the significance of 'cred' has been partially revealed to me.

In D20633#448011, @pho wrote:

I'm almost done with the amd64 tests and only found one instance of the printf:

20190621 13:21:33 all (235/646): mmap14.sh
_vm_map_clip_start: simplifying entry start 7fffdfdfe000 end 7fffdffde000 next_read 7fffdfdfd000 max_free 7ff7de9fc000 eflags 30000 object-type -1

Shall I move on to D20711?

Don't allocate swap space until the in-transition test is passed.

Relative to the previous version, combine the last two loops of vm_map_protect into one.

Reduce the swap_reserve calls to one, and not clip or modify map entry fields until it succeeds. This change makes an assumption about the need to check ptoa(obj->size) - that it isn't necessary when you the start and end of the map entry - that I'm believing because alc told me so.

Apply most reviewer suggestions. Explain the one I didn't apply.

By renaming, re-indenting, and updating stale comments, seek to answer questions and address reviewer concerns.

Add a header. Drop an extra argument to warn().