On Thu, 2007-06-07 at 17:10 +0800, Shaohua Li wrote: > On Wed, 2007-06-06 at 09:18 +0800, Shaohua Li wrote: > > On Tue, 2007-06-05 at 22:17 +0800, Avi Kivity wrote: > > > Shaohua Li wrote: > > > > Hi, > > > > This is a updated patch set of swap out kvm guest pages.Changes are: > > > > 1. refresh against to kvm-26 > > > > 2. clean up shadow page handling to make gfn_to_page not be called > > > > within kmap_atomic/kunamp_atomic. > > > > 3. variant bug fixing. Now the patch is quite stable in my test. > > > > 4. make swap out optional. A compile option can completely close > > > swap > > > > out. There should be no performance impact if swapout isn't enabled. > > > > > > > > There are still a lot of unresolved issues: > > > > 1. just work for one vm. waiting for kvm hook into scheduler > > > > 2. Not work for mp guest and can't swap out pages which shadow page > > > > table point to, this require kvm .flush_tlb can send ipi to vcpu. > > > > 3. swapoff isn't supported. We need a hook to sys_swapoff for kvm. > > > > > > > > Please review, suggests and comments are welcome. > > > > > > > > > > > > > > The patch rmaps read-only guest pages. While this is of course > > > required, it will make unshadowing ptes pointing to shared library > > > pages > > > very expensive. If we have a guest with 200 processes, all mapping > > > glibc, then an exit() will have to walk a linear list of size 200 per > > > shadowed pte. > > I'm doing performance test currently, will update you soon. > > > Do you know how the Linux rmap implementation handles this? > > In Linux, you can get the address_space from the page, then get all vmas > > of the address_space, then walking the page tables of all the vmas.It's > > also a linear list walking, I think. > I had some basic test results. The test is under a 1G memory host and > runs a 256M memory guest. There are nearly no swap. the benchmark is to > measure the time compile kernel source. With swap enabled, the > performance degrades about 9%. rmap read-only guest page hasn't any > performance impact. The degradation is caused by 'find_get_page', it > takes a lot of time, looks like it didn't handle big file well, but I > need time to do further check. I did a small optimization to bypass find_get_page if the page is already in page cache. With it, the swap patch set hasn't any performance degradation in the test environment above.
Thanks, Shaohua ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
