Re: Possible regression: XEN 4.0.0 total_memory decrease

["Jan Beulich" <JBeulich@novell.com>]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 16.04.10 19:37 >>>
>On 16/04/2010 08:53, "Jan Beulich" <JBeulich@novell.com> wrote:
>
>>>>> Keir Fraser <keir.fraser@eu.citrix.com> 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