[PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Andres Lagar-Cavilla]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

Contemplate 8MB of slack for PV domains, since they
do ballooning (or flipping network rx) and need
some extra room in their pfn space.

Note that this does not allocate any extra memory
to the domain, it simply extends the physmap with
some extra room for "bounce bufffering back" pfn's
that are yielded to dom0.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>


[-- Attachment #2: 03_8mb_pv_mem_slack.patch --]
[-- Type: text/plain, Size: 1212 bytes --]

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.com>
# Date 1259252810 18000
# Node ID ac2ad391d9290a5c554c9b809a6a23bb73aa25a2
# Parent  f5f07c0161eef51c265a1d0acbdf7da84cfc0fef
Contemplate 8MB of slack for PV domains, since they
do ballooning (or flipping network rx) and need
some extra room in their pfn space.

Note that this does not allocate any extra memory 
to the domain, it simply extends the physmap with
some extra room for "bounce bufffering back" pfn's 
that are yielded to dom0.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com> 

diff -r f5f07c0161ee -r ac2ad391d929 libxl_dom.c
--- a/libxl_dom.c
+++ b/libxl_dom.c
@@ -53,7 +53,8 @@ int build_pre(struct libxl_ctx *ctx, uin
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->vpt_align);
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->max_memkb + info->video_memkb);
-    xc_domain_set_memmap_limit(ctx->xch, domid, info->max_memkb);
+    xc_domain_set_memmap_limit(ctx->xch, domid, 
+            (info->hvm) ? info->max_memkb : (info->max_memkb + (8*1024)));
 
     if (info->hvm) {
         unsigned long shadow;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Stefano Stabellini]

On Wed, 2 Dec 2009, Andres Lagar-Cavilla wrote:
> Contemplate 8MB of slack for PV domains, since they
> do ballooning (or flipping network rx) and need
> some extra room in their pfn space.
> 
> Note that this does not allocate any extra memory
> to the domain, it simply extends the physmap with
> some extra room for "bounce bufffering back" pfn's
> that are yielded to dom0.
> 

Vincent is probably traveling and for this reason he didn't reply to
your last email about this patch.

I don't think he would be happy until you move the 8mb slack into a
configurable parameter in libxl_domain_build_info, defaulted to 8mb in
init_build_info.

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Vincent Hanquez]

On Wed, Dec 02, 2009 at 06:00:31PM +0000, Andres Lagar-Cavilla wrote:
> Contemplate 8MB of slack for PV domains, since they
> do ballooning (or flipping network rx) and need
> some extra room in their pfn space.
> 
> Note that this does not allocate any extra memory
> to the domain, it simply extends the physmap with
> some extra room for "bounce bufffering back" pfn's
> that are yielded to dom0.

but the memory is still going off from somewhere isn't it ?
all those random memory constants spread around in xend took us quite some time
to get things right in XCP and XenServer, and also for keeping the library as
dumb as possible, I'ld rather have the toolstack set the field in the structure
(even if it end up beeing 8M all the time) than starting adding those things.

-- 
Vincent

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Andres Lagar-Cavilla]

No extra memory is being allocated at all in any way. The only impact is 
a wee bit larger p2m table.
Andres
Vincent Hanquez wrote:
> On Wed, Dec 02, 2009 at 06:00:31PM +0000, Andres Lagar-Cavilla wrote:
>   
>> Contemplate 8MB of slack for PV domains, since they
>> do ballooning (or flipping network rx) and need
>> some extra room in their pfn space.
>>
>> Note that this does not allocate any extra memory
>> to the domain, it simply extends the physmap with
>> some extra room for "bounce bufffering back" pfn's
>> that are yielded to dom0.
>>     
>
> but the memory is still going off from somewhere isn't it ?
> all those random memory constants spread around in xend took us quite some time
> to get things right in XCP and XenServer, and also for keeping the library as
> dumb as possible, I'ld rather have the toolstack set the field in the structure
> (even if it end up beeing 8M all the time) than starting adding those things.
>
>   

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Vincent Hanquez]

On Thu, Dec 03, 2009 at 04:03:58PM +0000, Andres Lagar-Cavilla wrote:
> No extra memory is being allocated at all in any way. The only impact is 
> a wee bit larger p2m table.

yes, and that consumes memory. not sure that's one we care about in XCP,
but as a rule to not make any exceptions, i want the amount to be explicetly
tracked.

note that also, whilst xend didn't have much done regarding memory stuff,
xapi (the ocaml daemon running instead of xend in XCP) have load of changes
regarding how we allocate and track things.

-- 
Vincent

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[Andres Lagar-Cavilla]

The p2m is *inside* the pv guest. So the only "impact" is 
infinitesimally increasing the chances of an oom_killer going postal. 
This is not for hvm's with external p2m's
Andres
Vincent Hanquez wrote:
> On Thu, Dec 03, 2009 at 04:03:58PM +0000, Andres Lagar-Cavilla wrote:
>   
>> No extra memory is being allocated at all in any way. The only impact is 
>> a wee bit larger p2m table.
>>     
>
> yes, and that consumes memory. not sure that's one we care about in XCP,
> but as a rule to not make any exceptions, i want the amount to be explicetly
> tracked.
>
> note that also, whilst xend didn't have much done regarding memory stuff,
> xapi (the ocaml daemon running instead of xend in XCP) have load of changes
> regarding how we allocate and track things.
>
>   

[PATCH 3/7] libxenlight meta-resend: physmap slack for pv domains

[Andres Lagar-Cavilla]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Contemplate a memory space slack for PV domains,
since they do ballooning (or flipping network rx)
and need some extra room in their pfn space.

Note that this does not allocate any extra memory
to the domain, it simply extends the physmap with
some extra room for "bounce bufffering back" pfn's
that are yielded to dom0.

The default slack is set at 8MB.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>


[-- Attachment #2: 03_pv_mem_slack.patch --]
[-- Type: text/x-patch, Size: 1901 bytes --]

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.com>
# Date 1259856754 18000
# Node ID 7315ca037a680d18a6c23d030139b5389a73000b
# Parent  e64cd1042530990b49647d6eeb1c4167f02d4f19
Contemplate a memory space slack for PV domains,
since they do ballooning (or flipping network rx)
and need some extra room in their pfn space.

Note that this does not allocate any extra memory
to the domain, it simply extends the physmap with
some extra room for "bounce bufffering back" pfn's
that are yielded to dom0.

The default slack is set at 8MB.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>

diff -r e64cd1042530 -r 7315ca037a68 libxl.c
--- a/libxl.c
+++ b/libxl.c
@@ -2034,6 +2034,8 @@ void init_build_info(libxl_domain_build_
         b_info->u.hvm.acpi = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
+    } else {
+        b_info->u.pv.slack_memkb = 8 * 1024;
     }
 }
 
diff -r e64cd1042530 -r 7315ca037a68 libxl.h
--- a/libxl.h
+++ b/libxl.h
@@ -80,6 +80,7 @@ typedef struct {
             char *timeoffset;
         } hvm;
         struct {
+            uint32_t   slack_memkb;
             const char *cmdline;
             const char *ramdisk;
             const char *features;
diff -r e64cd1042530 -r 7315ca037a68 libxl_dom.c
--- a/libxl_dom.c
+++ b/libxl_dom.c
@@ -53,7 +53,9 @@ int build_pre(struct libxl_ctx *ctx, uin
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->vpt_align);
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->max_memkb + info->video_memkb);
-    xc_domain_set_memmap_limit(ctx->xch, domid, info->max_memkb);
+    xc_domain_set_memmap_limit(ctx->xch, domid, 
+            (info->hvm) ? info->max_memkb : 
+            (info->max_memkb + info->u.pv.slack_memkb));
 
     if (info->hvm) {
         unsigned long shadow;

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH 3/7] libxenlight meta-resend: physmap slack for pv domains

[Keir Fraser]

I don't think this one got Acked. I've applied all your other patches
however.

 -- Keir

On 03/12/2009 17:05, "Andres Lagar-Cavilla" <andres@lagarcavilla.com> wrote:

> Contemplate a memory space slack for PV domains,
> since they do ballooning (or flipping network rx)
> and need some extra room in their pfn space.
> 
> Note that this does not allocate any extra memory
> to the domain, it simply extends the physmap with
> some extra room for "bounce bufffering back" pfn's
> that are yielded to dom0.
> 
> The default slack is set at 8MB.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
> 

Re: [PATCH 3/7] libxenlight resend: 8mb physmap slack for pv domains

[andres]

I can cut the patch that way, however ... a fixed 8mb slack for pv domains
has been in place at least since Dec 08 2006, changeset 12803. No one
seems to have needed an optionally larger or smaller slack ;)
Andres
> On Wed, 2 Dec 2009, Andres Lagar-Cavilla wrote:
>> Contemplate 8MB of slack for PV domains, since they
>> do ballooning (or flipping network rx) and need
>> some extra room in their pfn space.
>>
>> Note that this does not allocate any extra memory
>> to the domain, it simply extends the physmap with
>> some extra room for "bounce bufffering back" pfn's
>> that are yielded to dom0.
>>
>
> Vincent is probably traveling and for this reason he didn't reply to
> your last email about this patch.
>
> I don't think he would be happy until you move the 8mb slack into a
> configurable parameter in libxl_domain_build_info, defaulted to 8mb in
> init_build_info.
>
>