Hi Sukanto, On Thu, Jul 03, 2008 at 08:34:58PM +0530, Sukanto Ghosh wrote: > > The current kvm without mmu-notifiers, can transparently swap guest > > pages only if they are not pointed by the shadow page tables. > > One a spte is instantiated the page cannot go to swap. > > Can you explain why spte's must be unmapped as well ?
Whenever a linux pagetable or a kvm spte is established, the page mapped by them has its reference count increased by 1. That tells the VM the page is referenced by someone and it prevents it to be swapped out. The page will look like it was swapped because the pte is successfully removed, the page will go in swapcache, but it will remain in ram as long as there's any spte still mapping it. mmu notifiers fixes this. > The memory region occupied by the structures maintaining the spte's > (kvm_mmu_page) they are also part of Linux VM. So why won't they be > swapped by Linux VM. > I didn't get the problem behind secondary MMU. sptes, ptes and all kernel data structures are never swapped. Only the userland memory (and in this case the guest physical ram) is entirely swapped. And any sptes still mapping a swapcache page prevents the swapcache to be written to disk and later freed. It's similar to O_DIRECT, when you do zerocopy dma to a page, you can't allow the page to be swapped out or the DMA will happen on freed ram. The page pinning mechanism works fine for temporary pins like O_DIRECT, but for sptes the pin can last forever if they're successfully cached. > ( I was going through the slides of presentation "Integrating with > the KVM Linux Memory Management" by Andrea Arcangeli : KVM Forum 2008 > ) You can check the picture, it shows the page being unmapped by the linux pte when linux swaps, but its reference count being still pinned if there are spte still mapping it. It also shows that with mmu notifiers the sptes don't take refcount anymore (or alternatively depending on the implementation the spte pin is removed at the same time the linux pte is zapped) and that allows the whole guest physical memory to be swapped as any other malloc. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
