From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: Pointed questions re Xen memory overcommit Date: Mon, 27 Feb 2012 15:40:39 -0800 (PST) Message-ID: <104d17ef-192d-4a13-9d19-b27a58f04384@default> References: <20120224214228.GA23473@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120224214228.GA23473@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: xen-devel@lists.xensource.com, Ian Campbell , Konrad Wilk , Lars Kurth , Kurt Hackel , Tim Deegan , Andres Lagar-Cavilla List-Id: xen-devel@lists.xenproject.org > From: Olaf Hering [mailto:olaf@aepfle.de] 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)). Dan