On 05/01/2010 10:40 PM, Dan Magenheimer wrote: >> Eventually you'll have to swap frontswap pages, or kill uncooperative >> guests. At which point all of the simplicity is gone. > > OK, now I think I see the crux of the disagreement. > > NO! Frontswap on Xen+tmem never *never* _never_ NEVER results > in host swapping. Host swapping is evil. Host swapping is > the root of most of the bad reputation that memory overcommit > has gotten from VMware customers. Host swapping can't be > avoided with some memory overcommit technologies (such as page > sharing), but frontswap on Xen+tmem CAN and DOES avoid it. > Why host-level swapping is evil? In KVM case, VM is just another process and host will just swap out pages using the same LRU like scheme as with any other process, AFAIK. Also, with frontswap, host cannot discard pages at any time as is the case will cleancache. So, while cleancache is obviously very useful, the usefulness of frontswap remains doubtful. IMHO, along with cleancache, we should just have in in-memory compressed swapping at *host* level i.e. no frontswap. I agree that using frontswap hooks, it is easy to implement ramzswap functionality but I think its not worth replacing this driver with frontswap hooks. This driver already has all the goodness: asynchronous interface, ability to dynamically add/remove ramzswap devices etc. All that is lacking in this driver is a more efficient 'discard' functionality so we can free a page as soon as it becomes unused. It should also be easy to extend this driver to allow sending pages to host using virtio (for KVM) or Xen hypercalls, if frontswap is needed at all. So, IMHO we can focus on cleancache development and add missing parts to ramzswap driver. Thanks, Nitin -- 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>