All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [RFC] Expose infrastructure for unpinning guest memory
Date: Fri, 12 Oct 2007 13:52:10 -0500	[thread overview]
Message-ID: <470FC25A.70607@us.ibm.com> (raw)
In-Reply-To: <470F14F2.7050800-atKUWr5tajBWk0Htik3J/w@public.gmane.org>

Avi Kivity wrote:
> Anthony Liguori wrote:
>   
>> Now that we have userspace memory allocation, I wanted to play with ballooning.
>> The idea is that when a guest "balloons" down, we simply unpin the underlying
>> physical memory and the host kernel may or may not swap it.  To reclaim
>> ballooned memory, the guest can just start using it and we'll pin it on demand.
>>
>> The following patch is a stab at providing the right infrastructure for pinning
>> and automatic repinning.  I don't have a lot of comfort in the MMU code so I
>> thought I'd get some feedback before going much further.
>>
>> gpa_to_hpa is a little awkward to hook, but it seems like the right place in the
>> code.  I'm most uncertain about the SMP safety of the unpinning.  Presumably,
>> I have to hold the kvm lock around the mmu_unshadow and page_cache release to
>> ensure that another VCPU doesn't fault the page back in after mmu_unshadow?
>>
>>   
>>     
>
> One we have true swapping capabilities (which imply ability for the
> kernel to remove a page from the shadow page tables) you can unpin by
> calling munmap() or madvise(MADV_REMOVE) on the pages to be unpinned.
>   

So does MADV_REMOVE remove the backing page but still allow for memory 
to be faulted in?  That is, after calling MADV_REMOVE, there's no 
guarantee that the contents of a give VA range will remain the same (but 
it won't SEGV the app if it accesses that memory)?

If so, I think that would be the right way to treat it.  That allows for 
two types of hints for the guest to provide: 1) I won't access this 
memory for a very long time (so it's a good candidate to swap out) and 
2) I won't access this memory and don't care about it's contents.

Regards,

Anthony Liguori

> Other than that the approach seems right.
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

  parent reply	other threads:[~2007-10-12 18:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11 21:32 [RFC] Expose infrastructure for unpinning guest memory Anthony Liguori
     [not found] ` <1192138344500-git-send-email-aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-10-11 21:59   ` Izik Eidus
     [not found]     ` <470E9CB6.4030107-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-11 22:18       ` Anthony Liguori
     [not found]         ` <470EA136.8020100-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-10-11 22:31           ` Izik Eidus
2007-10-12  0:11           ` Dor Laor
2007-10-12  6:32   ` Avi Kivity
     [not found]     ` <470F14F2.7050800-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-12 18:52       ` Anthony Liguori [this message]
     [not found]         ` <470FC25A.70607-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-10-13  7:21           ` Avi Kivity
2007-10-15  8:10           ` Carsten Otte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470FC25A.70607@us.ibm.com \
    --to=aliguori-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.