On Tue, Dec 13, 2011 at 4:45 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 12/12/2011 09:53 PM, Christoffer Dall wrote: >> > >> > A bigger problem is that you pin all memory; what are the plans wrt mmu >> > notifiers? >> > >> hmm, I have no plans (yet). >> >> I haven't looked into neither MMU shrinker nor MMU notifier. >> >> As I see it, the problems of consuming too much memory just for the >> page tables should be solved by somehow reclaiming pages used for the >> second stage mappings, > > That's what the shrinker does. > ok, that's what I thought. >> the question is just which mappings are the >> most efficient to reclaim. > > Do you have accessed bits in those PTEs? > nope. We can protect the underlying target pages though, but... > It's not really critical to have efficient reclaim here, since it > happens so rarely. It just needs to do something. > when would you trigger it - when it reaches a certain limit, or? And then what, free the lot and re-allocate what's needed? >> The other problem, the actual guest memory consuming too much memory, >> I assumed this limit would be set by the user when creating his/her >> VM, or can we do something smarter? (again, forgive my ignorance). >> What is the alternative to pinning actual guest pages > > mmu notifiers - pages aren't pinned; instead, Linux calls back into kvm > when modifying a host pte, and kvm responds by dropping or modifying its > translation (second stage pte in your case). > ah ok, so this works across VM boundary. Based on hyper-calls I presume? >> - as far as I >> know it's not common to have swap space on ARM architectures, but I >> could be wrong. > > It will become common once you start doing servers. > I think so too, but I am not sure if it's completely supported for ARM. Is it all arch-independent or do we miss arm-specific pieces? Marc? > mmu notifiers are also useful for other optimizations, like ksm, > ballooning, and transparent huge pages. > I know those features have to be supported eventually. The question is if all this must be in place before a merge upstream? Thanks, Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
