* [PATCH 03/14]: libxenlight, 8MB slack for PV domains
@ 2009-11-30 19:10 Andres Lagar-Cavilla
2009-12-01 6:34 ` Vincent Hanquez
0 siblings, 1 reply; 3+ messages in thread
From: Andres Lagar-Cavilla @ 2009-11-30 19:10 UTC (permalink / raw)
To: Stefano Stabellini, xen-devel
[-- Attachment #1: Type: text/plain, Size: 200 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.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
[-- Attachment #2: 03_8mb_pv_mem_slack.patch --]
[-- Type: text/x-patch, Size: 1032 bytes --]
# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.com>
# Date 1259252810 18000
# Node ID 5b7eed595f810af6a78aa17f28bfbdc0e5d11413
# Parent eba3584b89d66e702fe9c193c0391b379b9248a0
Contemplate 8MB of slack for PV domains, since they
do ballooning (or flipping network rx) and need
some extra room in their pfn space.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
diff -r eba3584b89d6 -r 5b7eed595f81 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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH 03/14]: libxenlight, 8MB slack for PV domains
2009-11-30 19:10 [PATCH 03/14]: libxenlight, 8MB slack for PV domains Andres Lagar-Cavilla
@ 2009-12-01 6:34 ` Vincent Hanquez
2009-12-01 14:15 ` Andres Lagar-Cavilla
0 siblings, 1 reply; 3+ messages in thread
From: Vincent Hanquez @ 2009-12-01 6:34 UTC (permalink / raw)
To: Andres Lagar-Cavilla; +Cc: xen-devel@lists.xensource.com, Stefano Stabellini
On Mon, Nov 30, 2009 at 07:10:58PM +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.
>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
this probably should be in the build structure. not magically adding 8 mb without the
toolstack knowing, otherwise no toolstack can provide more or less slacks on a
per domain basis. And it make precise memory handling a nightmare, and thus
dynamic memory handling too. in some way this parameter is just like the
shadow_memory one in the hvm build structure.
--
Vincent
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 03/14]: libxenlight, 8MB slack for PV domains
2009-12-01 6:34 ` Vincent Hanquez
@ 2009-12-01 14:15 ` Andres Lagar-Cavilla
0 siblings, 0 replies; 3+ messages in thread
From: Andres Lagar-Cavilla @ 2009-12-01 14:15 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: xen-devel@lists.xensource.com, Stefano Stabellini
The 8mb slack is not real memory allocated. It's extra room in the pfn
space. The memory's domain allocation remains capped at the amount
intended. I haven't seen anyone in xen-devel for five years needing more
slack than that ') Particularly since the network rx flipping path
stopped being the default
Andres
Vincent Hanquez wrote:
> On Mon, Nov 30, 2009 at 07:10:58PM +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.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.com>
>>
>
> this probably should be in the build structure. not magically adding 8 mb without the
> toolstack knowing, otherwise no toolstack can provide more or less slacks on a
> per domain basis. And it make precise memory handling a nightmare, and thus
> dynamic memory handling too. in some way this parameter is just like the
> shadow_memory one in the hvm build structure.
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-12-01 14:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-30 19:10 [PATCH 03/14]: libxenlight, 8MB slack for PV domains Andres Lagar-Cavilla
2009-12-01 6:34 ` Vincent Hanquez
2009-12-01 14:15 ` Andres Lagar-Cavilla
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.