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. > the question is just which mappings are the > most efficient to reclaim. Do you have accessed bits in those PTEs? It's not really critical to have efficient reclaim here, since it happens so rarely. It just needs to do something. > 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). > - 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. mmu notifiers are also useful for other optimizations, like ksm, ballooning, and transparent huge pages. -- error compiling committee.c: too many arguments to function -- 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
