From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Possible regression: XEN 4.0.0 total_memory decrease Date: Mon, 19 Apr 2010 08:35:53 +0100 Message-ID: <4BCC23F9020000780003AC6D@vpn.id2.novell.com> References: <4BC83396020000780003A934@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Xen-devel@lists.xensource.com" , Alex Williams List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 16.04.10 19:37 >>> >On 16/04/2010 08:53, "Jan Beulich" wrote: > >>>>> Keir Fraser 15.04.10 20:23 >>> >>> I've fixed this regression as xen-unstable:21190 and xen-4.0-testing:21= 114. >>> The fix will appear in Xen 4.0.1. >>=20 >> That seems wrong to me - I specifically changed the accounting so >> that pieces not used from the E820 map (which can no longer be cut >> off in e820.c, as that code doesn't know *where* to cut off) won't >> get reported as available memory. The real question is where (for >> the non-cut-off case) the two calculations differ. > >boot_e820 has chunks cut out of it for stashing kexec stuff, as well as = all >the multiboot modules. The value thereby obtained is just confusing to = users >who think we've binned possibly 100s of megabytes (if they run a big >initrd). The piece cut off for kexec imo shouldn't be counted as (usable) system RAM; the piece for the multiboot modules certainly should, but perhaps it would then be better to account for that explicitly instead of reporting a possibly much higher value than is actually available at runtime? Jan