All existing callers guarantee that the page does not have a pre-existing dequeue pending.

Can you add a KASSERT to express that in the callee?

Apply reviewer directives.

Seems plausible.

Simplify the patch.

Apply reviewer suggestions.

Ready for review....

.Dq late

line wrap.

Apply alc comments.

Use howmany in one more place.

Apply reviewer suggestions.

Make associated manpage fixes, including a clumsy attempt to address a savecore issue.

In D20863#459908, @dougm wrote:

Without changing the behavior of this patch, add a SW_TRIM flag and a priority field to swdevt. Pass those from sys_swapon to kern_swapon (which does the work formerly done by sys_swapon) to swaponsomething, which creates the swap object.

Without changing the behavior of this patch, add a SW_TRIM flag and a priority field to swdevt. Pass those from sys_swapon to kern_swapon (which does the work formerly done by sys_swapon) to swaponsomething, which creates the swap object.

Update log messages to distinguish cases where trimming is aborted before it gets started. Currently, a stretch of log entries like:

Fix function naming mismatches in KASSERTS. In wire/unwire, make sure to clip after first entry found in transition.

Don't unlock on early exit from map_wire_locked.

Get rid of the remaining uses of vm_map_simplify_entry.

Update after checking in overlapping changes.

Tidy up comments.

Apply reviewer suggestions. Make another style(9) fix.

Use vm_map_try_merge_entries instead of vm_simplify_entry in vm_map_inherit.

In looking for the map entry that includes the page before page 0, use &map->header explicitly instead of using vm_map_lookup_entry.

In one comment, connection -> descriptor.

Consume reviewer suggestions.

Rename vm_map_merge_entries to vm_map_try_merge_entries.

Fix broken log entry.

Stop updating blk before it might be freed.

Back out the changes that would launch more that one trim request from a single call to swp_pager_trimswapspace.

If trimming fails after blocks are allocated, free the blocks and reset the trimming cursor.

Don't let the trimmer sleep waiting for a resources. Don't invoke the trimmer while holding an object lock. Do let the trimmer launch as many delete ops as it wants, subject to resource constraints. Don't worry about trimming too little.

Add explanatory comment.

Fix Eflags typo.

Call swapon(2) after trimming, but before closing the trimming fd.

Code formatting and comment changes.

Edit comments.

Improve a comment.

Act on reviewer feedback.

Rename a variable. Restore a comment.

Make swapgeom_strategy() handle a BIO_DELETE just like a BIO_WRITE.

Bypass swp_pager_strategy for the BIO_DELETE case and just go to sp->sw_strategy(bp, sp);

Drop all the changes related to wiring and unwiring.

It would be unfair to Peter to keep guessing solutions for this problem and letting him try them out. Does anyone listening know what I've got wrong here?

Add an assertion. Use vm_paddr_t variable to manage bounds checking at function start.

g_io_request requires that b_data be NULL before BIO_DELETE. Make it so.

Don't try to trim exactly the swap device we just allocated from; just look for one that needs trimming.
Tweak the parameters to make the max trim size bigger, and make the trim zone smaller.

If we can allocation nothing from the next leaf, be sure to return immediately.

In the case that we have to back-up 'scan' because we've found that there's no next leaf with free blocks, we also have to back-up 'blk'.

Do I understand correctly that the "panic: freeing free block" condition is happening only with the patch from D20863 in place? Or does it happen with an unmodified kernel?

Correct the last log field.

Add logging. Don't really try to trim anything.

The obvious questions are:
Does this happen without the patch in place?
Does this happen before r349777?

In swap_pager_reserve, release the write lock when not modifying the object.