Please add your problematic workload descriptions to the list.  These workloads will be used as input on deciding how the VM needs to change, also see PageReplacementRequirements.

== Database, 128GB RAM, 2GB swap ==

In this scenario, the VM wastes a lot of time scanning through essentially unswappable pages.  Essentially unswappable because the amount of swap is negligable compared to the amount of total memory.  Besides, the users do not want their database processes or SHM segment swapped out anyway, unless it is absolutely necessary.

== Database + backup ==

While a backup is running, part of the working set of the database is evicted from memory.  Clearly this should not happen, since the database memory is accessed frequently, while the backup runs only once a day.  

This problem also happens to various other workloads when they get combined with a backup.  Updatedb can provoke a similar problem, sometimes even worse because the dentry and inode slab caches cannot be reclaimed as easily as page cache.

== Copy lots of data, then start the application ==

After copying a lot of data, an application is started to use that data.  Unfortunately, the VM sometimes ends up swapping out the application while keeping the data in memory.  It would be better if the data (page cache) would get evicted first.

== Very large working set ==

Some versions of Linux end up eating a lot of CPU time in the page reclaim code when an application references pretty much all memory. The issue is that whenever the pageout code scans memory, most pages will have been referenced.  Even if this is not an issue in the current Linux VM (need to verify), this kind of bug can be reintroduced very easily.

----
CategoryAdvancedPageReplacement