> I'd imagine modern systems wouldn't bother deleting a page in pagefile unless modified, but I don't actually know. Why would one bother deleting pages from the page file unless you have to?
They presumably use TRIM/UNMAP on SSDs when they're done with it because you'd otherwise have pages in the pagefile which are unused but the SSD can't erase to reallocate. Also, to keep track of whether a page has been modified after it has been swapped back in, memory writes would have to generate page faults just to allow the OS to mark the page as dirty, which is slow.
> Obviously, your percentage of modified pages to unmodified pages during swapping would be highly dependent on workload. But I imagine a good number of workloads have a lot of stuff in RAM that are somewhat static.
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, even if neither is being modified.
Also consider what would happen if pages were kept in the pagefile even after being swapped back in. You have 64GB of RAM and a 64.2GB working set. If pagefile pages are reused after being swapped back in, your pagefile is 0.2GB. If pages are left in the pagefile after being swapped back in, after one pass over the working set your pagefile is 64.2GB.
> 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.
They presumably use TRIM/UNMAP on SSDs when they're done with it because you'd otherwise have pages in the pagefile which are unused but the SSD can't erase to reallocate. Also, to keep track of whether a page has been modified after it has been swapped back in, memory writes would have to generate page faults just to allow the OS to mark the page as dirty, which is slow.
> Obviously, your percentage of modified pages to unmodified pages during swapping would be highly dependent on workload. But I imagine a good number of workloads have a lot of stuff in RAM that are somewhat static.
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, even if neither is being modified.
Also consider what would happen if pages were kept in the pagefile even after being swapped back in. You have 64GB of RAM and a 64.2GB working set. If pagefile pages are reused after being swapped back in, your pagefile is 0.2GB. If pages are left in the pagefile after being swapped back in, after one pass over the working set your pagefile is 64.2GB.