Re: [Xen-devel] [PATCH v6 11/23] libxl: functions to build vmemranges for PV guest

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-02-26 at 15:55 +0000, Wei Liu wrote:
> Introduce a arch-independent routine to generate one vmemrange per
> vnode. Also introduce arch-dependent routines for different
> architectures because part of the process is arch-specific -- ARM has
> yet have NUMA support and E820 is x86 only.
> 
> For those x86 guests who care about machine E820 map (i.e. with
> e820_host=1), vnode is further split into several vmemranges to
> accommodate memory holes.  A few stubs for libxl_arm.c are created.
> 
> Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

Although one comment:

> +    e820_count = 0;
> +    nr_vmemrange = 0;
> +    vmemranges = NULL;
> +    for (nid = 0; nid < b_info->num_vnuma_nodes; nid++) {
> +        libxl_vnode_info *p = &b_info->vnuma_nodes[nid];
> +        uint64_t remaining_bytes = (p->memkb << 10), bytes;
> +
> +        while (remaining_bytes > 0) {
> +            if (e820_count >= nr_e820) {
> +                rc = ERROR_NOMEM;
> +                goto out;
> +            }
> +
> +            /* Skip non RAM region */
> +            if (map[e820_count].type != E820_RAM) {
> +                e820_count++;
> +                continue;
> +            }
> +
> +            GCREALLOC_ARRAY(vmemranges, nr_vmemrange+1);

Once we've hit the limit this is going to reallocate every time (and the
limit starts as zero, so that's every time). Which means an aweful lot
of reallocing every time.

Perhaps start with some non-zero size and increase by a non-linear
amount as needed? That would require tracking the array size separate
from nr_vmemrange of course.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel