Re: VM memory allocation speed with cs 26056

[Zhigang Wang <zhigang.x.wang@oracle.com>]

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

On 11/12/2012 01:25 PM, Keir Fraser wrote:
> On 12/11/2012 15:01, "Zhigang Wang" <zhigang.x.wang@oracle.com> wrote:
>
>> Hi Keir/Jan,
>>
>> Recently I got a chance to access a big machine (2T mem/160 cpus) and I tested
>> your patch: http://xenbits.xen.org/hg/xen-unstable.hg/rev/177fdda0be56
>>
>> Attached is the result.
> The PVM result is weird, there is a small-ish slowdown for small domains,
> becoming a very large %age slowdown as domain memory increases, and then
> turning into a *speedup* as the memory size gets very large indeed.
>
> What are the error bars like on these measurements I wonder? One thing we
> could do to allow PV guests doing 4k-at-a-time allocations through
> alloc_heap_pages() to benefit from the TLB-flush improvements, is pull the
> filtering-and-flush out into populate_physmap() and increase_reservation().
> This is listed as a todo in the original patch (26056).
>
> To be honest I don't know why the original patch would make PV domain
> creation slower, and certainly not by a varying %age depending on domain
> memory size!
>
>  -- Keir
I did it second time. It seems the result (attached) is promising.

I think the strange result is due to the order of testing:
start_physical_machine -> test_hvm -> test_pvm.

This time, I did: start_physical_machine -> test_pvm -> test_hvm.

You can see the pvm memory allocation speed is not affected by your patch this time.

So I believe this patch is excellent now.

Thanks,

Zhigang


[-- Attachment #2: result.pdf --]
[-- Type: application/pdf, Size: 15643 bytes --]

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

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