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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Mar 02, 2015 at 03:41:21PM +0000, Ian Campbell wrote:
> 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>
> 

Thanks.

> 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.
> 

I've made some changes to have it increased by 32 elements every time.

Wei.

> Ian.

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