Tauist. Bit twiddler. Advocate for continued logarithms.
- User Since
- Jun 30 2017, 3:18 PM (112 w, 3 h)
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?
Wed, Aug 21
Apply reviewer directives.
Tue, Aug 20
Sat, Aug 17
Simplify the patch.
Apply reviewer suggestions.
Fri, Aug 16
Ready for review....
Thu, Aug 15
Wed, Aug 14
Fri, Aug 9
Use howmany in one more place.
Apply reviewer suggestions.
Thu, Aug 8
Make associated manpage fixes, including a clumsy attempt to address a savecore issue.
Tue, Aug 6
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.
Sat, Aug 3
Update log messages to distinguish cases where trimming is aborted before it gets started. Currently, a stretch of log entries like:
Thu, Aug 1
Wed, Jul 31
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.
Mon, Jul 29
Sun, Jul 28
Update after checking in overlapping changes.
Apply reviewer suggestions. Make another style(9) fix.
Sat, Jul 27
Fri, Jul 26
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.
Thu, Jul 25
In one comment, connection -> descriptor.
Jul 24 2019
Jul 23 2019
Consume reviewer suggestions.
Rename vm_map_merge_entries to vm_map_try_merge_entries.
Jul 22 2019
Jul 21 2019
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.
Jul 20 2019
Add explanatory comment.
Fix Eflags typo.
Call swapon(2) after trimming, but before closing the trimming fd.
Jul 19 2019
Code formatting and comment changes.
Improve a comment.
Jul 15 2019
Act on reviewer feedback.
Jul 14 2019
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?
Jul 13 2019
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.
Jul 12 2019
Jul 11 2019
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.
Jul 10 2019
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?
Jul 9 2019
Correct the last log field.
Add logging. Don't really try to trim anything.
Jul 8 2019
The obvious questions are:
Does this happen without the patch in place?
Does this happen before r349777?