On Fri, 2010-04-30 at 09:43 -0700, Dan Magenheimer wrote: > And, importantly, "have your host expose a device which is write > cached by host memory"... you are implying that all guest swapping > should be done to a device managed/controlled by the host? That > eliminates guest swapping to directIO/SRIOV devices doesn't it? If you have a single swap device, sure. But, I can also see a case where you have a "fast" swap and "slow" swap. The part of the argument about frontswap is that I like is the lack sizing exposed to the guest. When you're dealing with swap-only, you are stuck adding or removing swap devices if you want to "grow/shrink" the memory footprint. If the host (or whatever is backing the frontswap) wants to change the sizes, they're fairly free to. The part that bothers me it is that it just pushes the problem elsewhere. For KVM, we still have to figure out _somewhere_ what to do with all those pages. It's nice that the host would have the freedom to either swap or keep them around, but it doesn't really fix the problem. I do see the lack of sizing exposed to the guest as being a bad thing, too. Let's say we saved 25% of system RAM to back a frontswap-type device on a KVM host. The first time a user boots up their set of VMs and 25% of their RAM is gone, they're going to start complaining, despite the fact that their 25% smaller systems may end up being faster. I think I'd be more convinced if we saw this thing actually get used somehow. How is a ram-backed frontswap better than a /dev/ramX-backed swap file in practice? -- Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>