> because you'd otherwise have pages in the pagefile which are unused but the SSD can't erase to reallocate
> Also consider what would happen if pages were kept in the pagefile even after being swapped back in
In Windows, the pagefile doesn't grow and shrink based on you reading and writing pages. The pagefile.sys is usually a fixed size managed by the OS, and it will usually be several gigs in size even if you have say 100MB of "active" pages in the pagefile. On this Windows machine I use right now, the pagefile is set to ~25GB. pagefile.sys is this size regardless of if there's only 5MB of active pages in it or 20GB of pages in it. The pagefile.sys is the size it is until I go and modify the setting.
In Linux, swap is often a dedicated partition. It isn't going to shrink or grow based on its usage. And generally, a swapfile cannot be dynamically shrunk while online.
In fact, while there is an option to enable discards on swapon, it seems it doesn't always actually increase performance. I've been seeing a lot of debate with a lot of suggestions to not enable it.
> memory writes would have to generate page faults just to allow the OS to mark the page as dirty
The OS already knows the page is dirty and would need to be rewritten to properly swap out the page. It wouldn't have to always go to update the page in the swap/pagefile immediately on being marked dirty, only when it wants to swap out that page. In Windows, it reports this memory as "Modified", with the description of "memory whose contents must be written to disk before it can be used for another purpose". Meaning, it knows these pages are dirty, but it hasn't bothered touching the pagefile.sys yet to sync the page, largely because it doesn't have to as my machine still has plenty of free memory.
> Memory reads still cause swap writes because a page has to be evicted in order to make room in RAM for the one being swapped back in
Assuming it always deletes when a page gets read in. If both pages have previously been swapped, the page isn't dirty, and it doesn't just automatically delete on paging back in, it wouldn't have to do a write. Once again, significantly increasing performance. This is precisely why you wouldn't want to immediately delete the page from swap, because if the page is going to go back and forth between active memory and swap you might as well just leave it there.
You're also assuming that reading the page back into memory from swap inherently means another page has to be moving to swap. But this isn't always true; maybe some page was swapped out during a period of memory pressure, but now the system has more available memory. In this case (which probably happens often), reading that page back wouldn't require pages moving to swap.
Reading more about swap, it sounds like modern Linux uses an LRU caching strategy for memory pages in the swap cache. It doesn't explicitly go around deleting pages from swap unless it is going to reuse the page, or one has enabled discard=pages.
> When the reference count to the page finally reaches 0, the page is eligible to be dropped from the page cache and the swap map count will have the count of the number of PTEs the on-disk slot belongs to so that the slot will not be freed prematurely. It is laundered and finally dropped with the same LRU aging and logic described in Chapter 10.
> Also consider what would happen if pages were kept in the pagefile even after being swapped back in
In Windows, the pagefile doesn't grow and shrink based on you reading and writing pages. The pagefile.sys is usually a fixed size managed by the OS, and it will usually be several gigs in size even if you have say 100MB of "active" pages in the pagefile. On this Windows machine I use right now, the pagefile is set to ~25GB. pagefile.sys is this size regardless of if there's only 5MB of active pages in it or 20GB of pages in it. The pagefile.sys is the size it is until I go and modify the setting.
In Linux, swap is often a dedicated partition. It isn't going to shrink or grow based on its usage. And generally, a swapfile cannot be dynamically shrunk while online.
In fact, while there is an option to enable discards on swapon, it seems it doesn't always actually increase performance. I've been seeing a lot of debate with a lot of suggestions to not enable it.
https://www.man7.org/linux/man-pages/man8/swapon.8.html
> memory writes would have to generate page faults just to allow the OS to mark the page as dirty
The OS already knows the page is dirty and would need to be rewritten to properly swap out the page. It wouldn't have to always go to update the page in the swap/pagefile immediately on being marked dirty, only when it wants to swap out that page. In Windows, it reports this memory as "Modified", with the description of "memory whose contents must be written to disk before it can be used for another purpose". Meaning, it knows these pages are dirty, but it hasn't bothered touching the pagefile.sys yet to sync the page, largely because it doesn't have to as my machine still has plenty of free memory.
> Memory reads still cause swap writes because a page has to be evicted in order to make room in RAM for the one being swapped back in
Assuming it always deletes when a page gets read in. If both pages have previously been swapped, the page isn't dirty, and it doesn't just automatically delete on paging back in, it wouldn't have to do a write. Once again, significantly increasing performance. This is precisely why you wouldn't want to immediately delete the page from swap, because if the page is going to go back and forth between active memory and swap you might as well just leave it there.
You're also assuming that reading the page back into memory from swap inherently means another page has to be moving to swap. But this isn't always true; maybe some page was swapped out during a period of memory pressure, but now the system has more available memory. In this case (which probably happens often), reading that page back wouldn't require pages moving to swap.
Reading more about swap, it sounds like modern Linux uses an LRU caching strategy for memory pages in the swap cache. It doesn't explicitly go around deleting pages from swap unless it is going to reuse the page, or one has enabled discard=pages.
https://www.kernel.org/doc/gorman/html/understand/understand...
> When the reference count to the page finally reaches 0, the page is eligible to be dropped from the page cache and the swap map count will have the count of the number of PTEs the on-disk slot belongs to so that the slot will not be freed prematurely. It is laundered and finally dropped with the same LRU aging and logic described in Chapter 10.