Re: [RFC] Expose infrastructure for unpinning guest memory

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

Anthony Liguori wrote:
> 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.
You really want MADV_DONTNEED. It does what one would expect: tell the 
kernel you'd prefer to see it discarded but it remains mapped so that 
you can fault it in. My xip code got into conflice with subject kernel 
feature once, that's why I had to care what it does.

-------------------------------------------------------------------------
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/