Re: [Xen-devel] Pointed questions re Xen memory overcommit

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Feb 27, 2012 at 11:40 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
>> From: Olaf Hering [mailto:olaf@xxxxxxxxx]
>
> Hi Olaf --
>
> Thanks for the reply!  Since Tim answers my questions later in the
> thread, one quick comment...
>
>> To me memory overcommit means swapping, which is what xenpaging does:
>> turn the whole guest gfn range into some sort of virtual memory,
>> transparent to the guest.
>>
>> xenpaging is the red emergency knob to free some host memory without
>> caring about the actual memory constraints within the paged guests.
>
> Sure, but the whole point of increasing RAM in one or more guests
> is to increase performance, and if overcommitting *always* means
> swapping, why would anyone use it?
>
> So xenpaging is fine and useful, but IMHO only in conjunction
> with some other technology that reduces total physical RAM usage
> to less than sum(max_mem(all VMs)).

I agree -- overcommitting means giving the guests the illusion of more
aggregate memory than there is.  Paging is one way of doing that; page
sharing is another way.  The big reason paging is needed is if guests
start to "call in" the committments, by writing to previously shared
pages.  I would think tmem would also come under "memory overcommit".

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel