[lkml]   [2009]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux
    Dan Magenheimer wrote:
    > But this means that either the content of that page must have been
    > preserved somewhere or the discard fault handler has sufficient
    > information to go back and get the content from the source (e.g.
    > the filesystem). Or am I misunderstanding?

    As Rik said, it's the later.

    > With tmem, the equivalent of the "failure to access a discarded page"
    > is inline and synchronous, so if the tmem access "fails", the
    > normal code immediately executes.

    Yup. This is the main difference AFAICT. It's really just API
    semantics within Linux.

    You could clearly use the volatile state of CMM2 to implement tmem as an
    API in Linux. The get/put functions would set a flag such that if the
    discard handler was invoked as long as that operation happened, the
    operation could safely fail. That's why I claimed tmem is a subset of CMM2.

    > I suppose changing Linux to utilize the two tmem services
    > as described above is a semantic change. But to me it
    > seems no more of a semantic change than requiring a new
    > special page fault handler because a page of memory might
    > disappear behind the OS's back.
    > But IMHO this is a corollary of the fundamental difference. CMM2's
    > is more the "VMware" approach which is that OS's should never have
    > to be modified to run in a virtual environment. (Oh, but maybe
    > modified just slightly to make the hypervisor a little less
    > clueless about the OS's resource utilization.)

    While I always enjoy a good holy war, I'd like to avoid one here because
    I want to stay on the topic at hand.

    If there was one change to tmem that would make it more palatable, for
    me it would be changing the way pools are "allocated". Instead of
    getting an opaque handle from the hypervisor, I would force the guest to
    allocate it's own memory and to tell the hypervisor that it's a tmem
    pool. You could then introduce semantics about whether the guest was
    allowed to directly manipulate the memory as long as it was in the
    pool. It would be required to access the memory via get/put functions
    that under Xen, would end up being a hypercall and a copy. Presumably
    you would do some tricks with ballooning to allocate empty memory in Xen
    and then use those addresses as tmem pools. On KVM, we could do
    something more clever.

    The big advantage of keeping the tmem pool part of the normal set of
    guest memory is that you don't introduce new challenges with respect to
    memory accounting. Whether or not tmem is directly accessible from the
    guest, it is another memory resource. I'm certain that you'll want to
    do accounting of how much tmem is being consumed by each guest, and I
    strongly suspect that you'll want to do tmem accounting on a per-process
    basis. I also suspect that doing tmem limiting for things like cgroups
    would be desirable.

    That all points to making tmem normal memory so that all that
    infrastructure can be reused. I'm not sure how well this maps to Xen
    guests, but it works out fine when the VMM is capable of presenting
    memory to the guest without actually allocating it (via overcommit).


    Anthony Liguori

     \ /
      Last update: 2009-07-10 01:35    [W:0.062 / U:30.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site