WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Possible regression: XEN 4.0.0 total_memory decrease

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Possible regression: XEN 4.0.0 total_memory decrease
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 19 Apr 2010 08:35:53 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williams <awilliams@xxxxxxxx>
Delivery-date: Mon, 19 Apr 2010 00:36:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C7EE5EF0.11823%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BC83396020000780003A934@xxxxxxxxxxxxxxxxxx> <C7EE5EF0.11823%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 16.04.10 19:37 >>>
>On 16/04/2010 08:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 15.04.10 20:23 >>>
>>> I've fixed this regression as xen-unstable:21190 and xen-4.0-testing:21114.
>>> The fix will appear in Xen 4.0.1.
>> 
>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel