In continuing digging through the swap code (with the overall objective of improving zcache policy), I was looking at the size of the swapcache. My understanding was that the swapcache is simply a buffer cache for pages that are actively in the process of being swapped in or swapped out. And keeping pages around in the swapcache is inefficient because every process access to a page in the swapcache causes a minor page fault. So I was surprised to see that, under a memory intensive workload, the swapcache can grow quite large. I have seen it grow to almost half of the size of RAM. Digging into this oddity, I re-discovered the definition for "vm_swap_full()" which, in scan_swap_map() is a pre-condition for calling __try_to_reclaim_swap(). But vm_swap_full() compares how much free swap space there is "on disk", with the total swap space available "on disk" with no regard to how much RAM there is. So on my system, which is running with 1GB RAM and 10GB swap, I think this is the reason that swapcache is growing so large. Am I misunderstanding something? Or is this code making some (possibly false) assumptions about how swap is/should be sized relative to RAM? Or maybe the size of swapcache is harmless as long as it doesn't approach total "on disk" size? (Sorry if this is a silly question again...) Thanks, Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href