Kostik, Mark,

I have a question about vm_object_split() and swap_pager_copy(). vm_object_split() is indirectly dirtying every transferred, because vm_page_rename() always performs vm_page_dirty(). But, that dirtying is not freeing the allocated swap. Instead, we are copying it. The obvious thing would be to release the swap when the page is dirtied, but does the vm_page_rename() by vm_object_split() actually need to dirty the page given that it is also performing swap_pager_copy()? If a transferred page is reclaimed, because it is currently clean, then we should be able to recover the data from swap.

In D13707#352645, @alc wrote:

Kostik, Mark,

I have a question about vm_object_split() and swap_pager_copy(). vm_object_split() is indirectly dirtying every transferred, because vm_page_rename() always performs vm_page_dirty(). But, that dirtying is not freeing the allocated swap. Instead, we are copying it. The obvious thing would be to release the swap when the page is dirtied, but does the vm_page_rename() by vm_object_split() actually need to dirty the page given that it is also performing swap_pager_copy()? If a transferred page is reclaimed, because it is currently clean, then we should be able to recover the data from swap.

I can't see any problem with the reasoning the last sentence. The behaviour of vm_page_rename() marking the page dirty was introduced in r42957, but existed in vm_map_split() even before that: it was added in r35571 with a somewhat enigmatic commit log message. At that point, we weren't busying each page during the transfer - before that was added, I think the dirtying would have been necessary to prevent a race with reclamation by the page daemon?

In D13707#352661, @markj wrote:

In D13707#352645, @alc wrote:

Kostik, Mark,

I have a question about vm_object_split() and swap_pager_copy(). vm_object_split() is indirectly dirtying every transferred, because vm_page_rename() always performs vm_page_dirty(). But, that dirtying is not freeing the allocated swap. Instead, we are copying it. The obvious thing would be to release the swap when the page is dirtied, but does the vm_page_rename() by vm_object_split() actually need to dirty the page given that it is also performing swap_pager_copy()? If a transferred page is reclaimed, because it is currently clean, then we should be able to recover the data from swap.

I can't see any problem with the reasoning the last sentence. The behaviour of vm_page_rename() marking the page dirty was introduced in r42957, but existed in vm_map_split() even before that: it was added in r35571 with a somewhat enigmatic commit log message. At that point, we weren't busying each page during the transfer - before that was added, I think the dirtying would have been necessary to prevent a race with reclamation by the page daemon?

As I see, vm_object_scan() does exactly this: vm_object_collapse_scan() renames the page and then frees the backing swap.

Peter, could you please test this patch.

In D13707#352682, @alc wrote:

Peter, could you please test this patch.

I tested this with all of the stress2 tests on amd64. I also did a buildworld.
On i386 I ran about half of the tests, until I got an unrelated PMC panic.
LGTM.