From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: Pointed questions re Xen memory overcommit Date: Wed, 29 Feb 2012 11:43:08 +0100 Message-ID: <20120229104308.GA23724@aepfle.de> References: <20120224214228.GA23473@aepfle.de> <104d17ef-192d-4a13-9d19-b27a58f04384@default> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <104d17ef-192d-4a13-9d19-b27a58f04384@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dan Magenheimer 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 On Mon, Feb 27, Dan Magenheimer wrote: > > From: Olaf Hering [mailto:olaf@aepfle.de] > > 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? The usage patterns depend on the goal. As I wrote, swapping frees host memory so it can be used for something else, like starting yet another guest on the host. Olaf