[Mavrick] SRU: Set maximum of domain visible memory to 70G

SRU justification:

Impact: The config option XEN_MAX_DOMAIN_MEMORY controls how much memory
a Xen instance is seeing. The default for 64bit is 32GB, which is the
reason that m2.4xlarge instances only report this amount of memory.

Fix: Setting this limit to 70GB as there is a known restriction for
t1.micro instances at about 80GB.

Testcase: Booted m2.4xlarge with this set to 32GB shows 32GB of memory,
when set to 70GB, it correctly reports 68GB. Booted a t1.micro as well
to verify this has not caused problems there.

From c72705539ee164cdd100570c1340887f81a63d98 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Thu, 9 Dec 2010 17:59:36 +0100
Subject: [PATCH] UBUNTU: Set maximum of domain visible memory to 70G

BugLink: http://bugs.launchpad.net/bugs/667796

Otherwise the largest instances will be stuck with 32G of memory. 70G
was chosen as there are some known problems on small instances around
80GB and the largest instance is using 68GB.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 debian.master/config/config.common.ubuntu |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

On 12/10/2010 07:10 AM, Stefan Bader wrote:
> SRU justification:
>
> Impact: The config option XEN_MAX_DOMAIN_MEMORY controls how much memory
> a Xen instance is seeing. The default for 64bit is 32GB, which is the
> reason that m2.4xlarge instances only report this amount of memory.
>
> Fix: Setting this limit to 70GB as there is a known restriction for
> t1.micro instances at about 80GB.
>
> Testcase: Booted m2.4xlarge with this set to 32GB shows 32GB of memory,
> when set to 70GB, it correctly reports 68GB. Booted a t1.micro as well
> to verify this has not caused problems there.
>
>  From c72705539ee164cdd100570c1340887f81a63d98 Mon Sep 17 00:00:00 2001
> From: Stefan Bader<stefan.bader@canonical.com>
> Date: Thu, 9 Dec 2010 17:59:36 +0100
> Subject: [PATCH] UBUNTU: Set maximum of domain visible memory to 70G
>
> BugLink: http://bugs.launchpad.net/bugs/667796
>
> Otherwise the largest instances will be stuck with 32G of memory. 70G
> was chosen as there are some known problems on small instances around
> 80GB and the largest instance is using 68GB.
>
> Signed-off-by: Stefan Bader<stefan.bader@canonical.com>
> ---
>   debian.master/config/config.common.ubuntu |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/debian.master/config/config.common.ubuntu b/debian.master/config/config.common.ubuntu
> index b0c486b..ed8ad01 100644
> --- a/debian.master/config/config.common.ubuntu
> +++ b/debian.master/config/config.common.ubuntu
> @@ -5014,7 +5014,7 @@ CONFIG_XEN_COMPAT_XENFS=y
>   CONFIG_XEN_DEV_EVTCHN=m
>   CONFIG_XEN_FBDEV_FRONTEND=m
>   CONFIG_XEN_KBDDEV_FRONTEND=m
> -CONFIG_XEN_MAX_DOMAIN_MEMORY=32
> +CONFIG_XEN_MAX_DOMAIN_MEMORY=70
>   CONFIG_XEN_SAVE_RESTORE=y
>   CONFIG_XEN_SCRUB_PAGES=y
>   CONFIG_XEN_SYS_HYPERVISOR=y

Any thoughts on the impact this change will have on -generic and 
-server? Perhaps we should restrict this change to the -ec2 flavour only.

rtg

On 12/10/2010 03:52 PM, Tim Gardner wrote:
> On 12/10/2010 07:10 AM, Stefan Bader wrote:
>> SRU justification:
>>
>> Impact: The config option XEN_MAX_DOMAIN_MEMORY controls how much memory
>> a Xen instance is seeing. The default for 64bit is 32GB, which is the
>> reason that m2.4xlarge instances only report this amount of memory.
>>
>> Fix: Setting this limit to 70GB as there is a known restriction for
>> t1.micro instances at about 80GB.
>>
>> Testcase: Booted m2.4xlarge with this set to 32GB shows 32GB of memory,
>> when set to 70GB, it correctly reports 68GB. Booted a t1.micro as well
>> to verify this has not caused problems there.
>>
>>  From c72705539ee164cdd100570c1340887f81a63d98 Mon Sep 17 00:00:00 2001
>> From: Stefan Bader<stefan.bader@canonical.com>
>> Date: Thu, 9 Dec 2010 17:59:36 +0100
>> Subject: [PATCH] UBUNTU: Set maximum of domain visible memory to 70G
>>
>> BugLink: http://bugs.launchpad.net/bugs/667796
>>
>> Otherwise the largest instances will be stuck with 32G of memory. 70G
>> was chosen as there are some known problems on small instances around
>> 80GB and the largest instance is using 68GB.
>>
>> Signed-off-by: Stefan Bader<stefan.bader@canonical.com>
>> ---
>>   debian.master/config/config.common.ubuntu |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/debian.master/config/config.common.ubuntu
>> b/debian.master/config/config.common.ubuntu
>> index b0c486b..ed8ad01 100644
>> --- a/debian.master/config/config.common.ubuntu
>> +++ b/debian.master/config/config.common.ubuntu
>> @@ -5014,7 +5014,7 @@ CONFIG_XEN_COMPAT_XENFS=y
>>   CONFIG_XEN_DEV_EVTCHN=m
>>   CONFIG_XEN_FBDEV_FRONTEND=m
>>   CONFIG_XEN_KBDDEV_FRONTEND=m
>> -CONFIG_XEN_MAX_DOMAIN_MEMORY=32
>> +CONFIG_XEN_MAX_DOMAIN_MEMORY=70
>>   CONFIG_XEN_SAVE_RESTORE=y
>>   CONFIG_XEN_SCRUB_PAGES=y
>>   CONFIG_XEN_SYS_HYPERVISOR=y
> 
> Any thoughts on the impact this change will have on -generic and
> -server? Perhaps we should restrict this change to the -ec2 flavour only.
> 
> rtg

As far as I understand it, this value is only used in the xen mmu code when
setting up domU. The comment there says, it is in that case using a page per GB.
But as we have the virtual flavour, it probably makes sense to use it.

-Stefan