Tudor-Ioan Salomie [PERSONAL]
2013-Aug-28 15:16 UTC
Investigating memory performance: bare metal vs. xen-pv vs. xen-hvm
I''ve been trying to compare memory access speed between bare-metal,
xen-pv
and xen-pvhvm (hvm with pv drivers). In all 3 setups I''m running the
same
kernel (3.6.6), built with support for xen, on a 64 core AMD Opteron 6378.
The output of xm info (relevant parts):
machine : x86_64
nr_cpus : 64
nr_nodes : 8
cores_per_socket : 16
threads_per_core : 1
cpu_mhz : 2400
hw_caps :
178bf3ff:2fd3fbff:00000000:00001710:32983203:00000000:01ebbfff:00000008
virt_caps : hvm
total_memory : 524262
free_memory : 498318
free_cpus : 0
xen_major : 4
xen_minor : 1
xen_extra : .2
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : Tue Apr 10 10:50:08 2012 +0200 12:efd10c64454c
xen_commandline : auto BOOT_IMAGE=user-xen root=801 placeholder
no-bootscrub dom0_mem=4096M dom0_max_vcpus=16 dom0_vcpus_pin root=/dev/sda1
noreboot
cc_compiler : gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
To avoid as much noise as possible I''ve got a kernel module in which
I''m
performing the following straight forward test:
for (j = 2; j < 18; j++) {
cpysize = 1 << j;
cpycnt = size / cpysize;
do_gettimeofday(&tvb);
for (i = 0; i < loops; ++i) {
for (k = 0; k < cpycnt; ++k) {
memcpy(src+k*cpysize,dst+k*cpysize,cpysize);
}
}
do_gettimeofday(&tve);
msec = timevaldiff(&tvb, &tve);
printk(KERN_INFO "Did the loops in %ld msec for cpysize = %d \n",
msec,
cpysize);
}
Where src and dst were allocate with vmalloc of size "size". Also, src
is
initialized with 0s.
Since it''s the same code, run within the kernel, I would have expected
the
obvious: bare metal to be the fastest, then pvhvm and then pv. Curiously,
the numbers I get (summarized in the table below), contradict my assumption:
time (msec) - 100 loops over 16MB chunk size (cpysize) bare metal pvhvm pv
4 5827 4606 4971 8 3865 3030 3448 16 3177 2134 2270 32 3241 2216 2059 64
1009 943 925 128 760 599 566 256 767 592 559 512 727 587 544 1024 701
575 524 2048 688 570 507 4096 678 566 498 8192 662 552 489 16384 652 542
480 32768 646 539 478 65536 644 535 474 131072 643 535 473
The peculiar observations:
================1. bare metal seems to be slower in all cases (???)
2. pvhvm is faster then pv, but only for small chunks
3. for large chunks, the order is the reverse one of what I would have
anticipated: pv (fastest), pvhvm then bare metal (slowest).
Does anyone have any ideas why this might be happening?
Am I missing something?
Cheers,
-- Tudor.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
