From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] linux/balloon: don't allow ballooningdowna domain below a reasonable limit Date: Wed, 30 Apr 2008 10:04:05 -0600 Message-ID: <20080430100405828.00000002360@djm-pc> References: <48182DE2.76E4.0078.0@novell.com> Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <48182DE2.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Ky Srinivasan , "xen-devel@lists.xensource.com" , Keir Fraser , KurtGarloff List-Id: xen-devel@lists.xenproject.org Hi Jan -- Thanks for the reply. I see the comment now... it didn't find its way into the source. I will definitely be working on tuning this estimate as I am working on maximizing the number of domains that can be run on a system and this is a constraint. As a quick-and-dirty test, I just divided the result of your algorithm (on a 512MB domain) by two and the maximally-ballooned kernel still ran fine (with 86528kB instead of 173056kB). Could you explain the logic behind your current algorithm? I understand you are trying to estimate the additional kernel data structure space with the addition of the max_pfn computation but don't understand why this is a good estimator. I also am wondering how you chose the magic values for x in MB2PAGES(x). And also if you have any tests/workloads you might have used to evaluate the algorithm. Thanks, Dan > -----Original Message----- > From: Jan Beulich [mailto:jbeulich@novell.com] > Sent: Wednesday, April 30, 2008 12:29 AM > To: dan.magenheimer@oracle.com > Cc: Keir Fraser; xen-devel@lists.xensource.com; Ky Srinivasan; > KurtGarloff > Subject: RE: [Xen-devel] [PATCH] linux/balloon: don't allow > ballooningdowna domain below a reasonable limit > = > = > >>> "Dan Magenheimer" 29.04.08 20:35 >>> > >I made some actual measurements of the results of this algorithm > >(on a RHEL5u1-32bit guest). > > > >memory=3D Minimum > >128 75776kB > >256 108544kB > >512 173056kB > >1024 238592kB > > > >This corresponds to expected values in the source comment > >However, I wonder if the algorithm is probably too > >conservative for large(r) memory domains. With > >a light load (i.e. continuously compiling Xen), > >memory utilization rarely exceeds 72MB, regardless > >of the max memory (at least in the above tested values). > = > Sure, this was (in different wording) also stated in the comment > that came with the patch. A more precise estimate would certainly > be welcome, but I'm afraid is going to come with a much higher > (complexity) price tag. Unless you have something simple and > obvious in mind that we simply didn't spot... > = > Jan > = >