Re: [Xen-devel] VM memory allocation speed with cs 26056

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Subject: Re: VM memory allocation speed with cs 26056
> 
> >>> On 12.11.12 at 16:01, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx> wrote:
> > My conclusion from the test:
> >
> >   - HVM create time is greatly reduced.
> >   - PVM create time is increased dramatically for 4G, 8G, 16G, 32G, 64G, 
> > 128G.
> >   - HVM/PVM destroy time is not affected.
> >   - If most of our customers are using PVM, I think this patch is bad: 
> > because
> > most VM memory should under 128G.
> >   - If they are using HVM, then this patch is great.
> >
> > Questions for discussion:
> >
> >   - Did you get the same result?
> >   - It seems this result is not ideal. We may need to improve it.
> 
> We'd first of all need to understand how this rather odd behavior
> can be explained. In order to have a better comparison basis, did
> you also do this for traditional PV? Or maybe I misunderstand
> what PVM stands for, and am mixing it up with PVH? You certainly
> agree that the two curves for what you call PVM have quite
> unusual a relationship.

("PVM" is unfortunately often used within Oracle and means the
same as "PV".  "PVM" == paravirtualized virtual machine.)

One significant difference is that a PV domain always allocates
memory one 4K page at a time and the patch improves allocation
performance only for larger-order allocations.  A reasonable
hypothesis is that the patch reduces performance on long
sequences of 4K pages, though this doesn't explain the curve
of the PV_create measurements at 256G and above.

With a one-line* hypervisor patch in alloc_heap_pages, one can
change HVM allocation so that all larger allocations are rejected.
It would be very interesting to see if that would result in an HVM
create curve similar to the PV create curve.

* change "unlikely(order > MAX_ORDER)" to "order > 0"

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