Avi Kivity wrote:
Andrew Morton wrote:
The whole approach seems wrong to me. The kernel lost track of these
pages and then we run around post-facto trying to fix that up again.
Please explain (for the changelog) why the kernel cannot get this right
via the usual sharing, refcounting and COWing approaches.
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.
As Avi said, in kvm we cannot know how the guest is going to map its
pages, we have nothing to do but to scan for the identical pages
(you can have pages that are shared that are in whole different offset
inside the guest)
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).
--
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
