|From:||Avi Kivity <avi-AT-redhat.com>|
|To:||Andrew Morton <akpm-AT-linux-foundation.org>|
|Subject:||Re: [PATCH 0/4] ksm - dynamic page sharing driver for linux|
|Date:||Tue, 11 Nov 2008 21:29:34 +0200|
|Cc:||ieidus-AT-redhat.com, linux-kernel-AT-vger.kernel.org, linux-mm-AT-kvack.org, kvm-AT-vger.kernel.org, aarcange-AT-redhat.com, chrisw-AT-redhat.com|
Andrew Morton wrote: >> For kvm, the kernel never knew those pages were shared. They are loaded >> from independent (possibly compressed and encrypted) disk images. These >> images are different; but some pages happen to be the same because they >> came from the same installation media. >> > > What userspace-only changes could fix this? Identify the common data, > write it to a flat file and mmap it, something like that? > > This was considered. You can't scan the image, because it may be encrypted/compressed/offset (typical images _are_ offset because the first partition starts at sector 63...). The data may come from the network and not a disk image. You can't scan in userspace because the images belong to different users and contain sensitive data. Pages may come from several images (multiple disk images per guest) so you end up with one vma per page. So you have to scan memory, after the guest has retrieved it from disk/network/manufactured it somehow, decompressed and encrypted it, written it to the offset it wants. You can't scan from userspace since it's sensitive data, and of course the actual merging need to be done atomically, which can only be done from the holy of holies, the vm. >> For OpenVZ the situation is less clear, but if you allow users to >> independently upgrade their chroots you will eventually arrive at the >> same scenario (unless of course you apply the same merging strategy at >> the filesystem level). >> > > hm. > > There has been the occasional discussion about idenfifying all-zeroes > pages and scavenging them, repointing them at the zero page. Could > this infrastructure be used for that? Yes, trivially. ksm may be an overkill for this, though. > (And how much would we gain from > it?) > A lot of zeros. > [I'm looking for reasons why this is more than a muck-up-the-vm-for-kvm > thing here ;) ] > I sympathize -- us too. Consider the typical multiuser gnome minicomputer with all 150 users reading lwn.net at the same time instead of working. You could share the firefox rendered page cache, reducing memory utilization drastically. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds