On Wed, Jul 2, 2008 at 7:41 AM, Dor Laor <[EMAIL PROTECTED]> wrote: >> In theory an attempt by the guest to access a page that has been >> swapped out by the host should take much longer than accessing a page >> that is in memory. > > Your assumption is correct for userspace allocation inside the guest. > Let me explain: > > 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. mmu notifiers > will cancel this limitation and we'll get notifications about page > swapping from the host MM. > > IIRC guest kernel allocations has the global bit set, thus we optimize > the shadow mmu not to flush global guest pages, so if this assumption is > correct, you won't feel the difference.
I didn't quite understand that last part. Does this mean that a guest's pages can be swapped out by the host but if the guest kernel tries to access that page it won't notice a difference. That seems a bit counterintuitive to me. Is there a difference when the guest kernel maps some of its processes pages into its kernel space ? Do such pages get treated differently ? Let me recap on what I expect in steps : 1) KVM Guest is running on host. 2) Host needs physical memory for other purposes so host swaps out some of guests pages and hands them over to other process. 3) Guest is not aware that some of its pages are swapped out by host. 4) Now guest kernel maps some of these pages into its kernel space (guest kernel space) (it still doesn't know that pages have been swapped out) 5) Guest kernel then tries to read a byte from a swapped out page. 6) This causes some kind of trap/interception by host who swaps the page in and hands control back to guest kernel. 7) Guest kernel then proceeds to read a byte from the page, only now its taken longer to read the byte than it would have had the page not been swapped out. Basically, if a guest's pages have been swapped out by host and used for another process, then when the guest kernel tries to access that page, there will be some delay while the host handles the request. Would appreciate further info on this. > Anyway what's your motivation for this module? Its something I'm working on on part of a larger project related to resource allocation and guarantees to guest VMs. Thanks Arn >> me know if I'm missing something crucial in my assumptions ? I'm using >> an amd64 machine with host/guest kernel 2.6.22 and kvm-64 -- 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
