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().

Just to be clear, I understand that this latest patch produces no printfs on amd64, but only on i386, and the previous version produces printfs on both architectures. Is that understanding correct?

In D20633#447540, @pho wrote:

I see lots of _vm_map_clip_start on i386 with D20633.58825.diff.
https://people.freebsd.org/~pho/stress/log/dougm034.txt

I've identified a case where vm_map_protect leaves an entry un-simplified, and attempted to address it. I hope to discover whether the number of simplify_entry calls logged as necessary in clip_start is reduced by this change.

Addressed reviewer comments about these changes.

... but keep the boolean_t to bool return value transition for vm_map_entry_lookup.

Too many places depend on the vm_map_entry_lookup name, so leave it alone and rename something else.

Most of these changes are distractions, unrelated to your real purpose. I suggest you get rid of them. What's left is you removing a bug fix from 2003 without any explanation about why that fix is no longer necessary, and you fixing a bug that hasn't been filed with no real explanation of how it is a fix. I don't think anyone has enough information to approve this change.

Endeavor to apply reviewer suggestions.

Just to be clear, I understand you to be saying that the map11 test produces the four lines of output above and no other tests, including buildworld/installworld, produce any such output. Is that correct?

Make it compile.

Apply reviewer suggestion.

Write information about the cases in which clip_start requires entry simplification, with the hope that the origins of those cases can be identified and that simplification happen elsewhere.

Leave out unrelated patches.

Separate the comments and code blocks for 'create backing object' from 'clone entry'.

Can you update this patch, please, at least so that it can be applied? Part of it was put into a separate patch and has already been put in head.

Update comments in accordance with suggestions from alc.

Address reviewer comments.

Change bool literals to boolean_t literals in some places. Change u_ints to u_longs, and add a check for overflow. Truncate in computing hi.

Accept reviewer suggestions for changes to u_int for hi, lo and npages.

Restrict the scope of this patch just to reducing code duplication. On this amd64, it reduces the size of vm_map.o from 456608 to 455816, with no obvious impact on performance.

Ignore this patch while I study an unexpected negative performance impact.

Restore a patch that got accidentally copied over last week.