[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] CAP and performance problem
On mar, 2013-05-21 at 11:02 +0200, Massimo Canonico wrote: > Hi, > Hi again, > I sent the following problem on xen-user ML without an answer. I hope > I'll get one in this ML. > > My application is written in std C++ and it makes a matrix > multiplication: so it uses only CPU and memory (no I/O, no network). > > I'm quite surprise that with CAP = 100% I got my results in about 600 > seconds and with CAP = 50% I got my results in about 1800 seconds > (around 3 times longer). > > For this kind of application I was expecting to get results in about > 1200 seconds (2 times longer) for the second scenario with respect to > the first one. > > Of course, the HW and SW are exactly the same for the 2 experiments. > > Am I wrong or the CAP mechanism is not working well? > Ok, I found a minute to run your code myself on my test box. It's quite a large one, but since the VM has only 1 vcpu, that shouldn't really make much difference. I configured vcpu-pinning in such a way that there should be no room for interference of any kind, i.e., dedicating a core to the VM, and making sure even his fellow thread is not busy (which matters in an hyperthreaded system): # xl vcpu-list Name ID VCPU CPU State Time(s) CPU Affinity Domain-0 0 0 7 -b- 38.7 0-7 Domain-0 0 1 3 -b- 2.3 0-7 Domain-0 0 2 2 -b- 3.3 0-7 Domain-0 0 3 6 -b- 6.8 0-7 Domain-0 0 4 4 -b- 3.2 0-7 Domain-0 0 5 2 -b- 3.6 0-7 Domain-0 0 6 4 -b- 2.1 0-7 Domain-0 0 7 1 -b- 1.8 0-7 Domain-0 0 8 0 -b- 2.2 0-7 Domain-0 0 9 7 -b- 1.7 0-7 Domain-0 0 10 1 -b- 1.8 0-7 Domain-0 0 11 5 r-- 10.4 0-7 Domain-0 0 12 1 -b- 3.5 0-7 Domain-0 0 13 2 -b- 3.5 0-7 Domain-0 0 14 3 -b- 2.7 0-7 Domain-0 0 15 0 -b- 1.9 0-7 vm1 1 0 11 -b- 677.0 11 The numbers I'm getting are, I think, much more consistent with the expectations: * no cap: Client served in 299.024 Client served in 298.783 Client served in 298.445 * cap 50%: Client served in 643.668 Client served in 643.372 Client served in 644.342 Which means time roughly doubles. I tried without pinning as well, and I'm getting pretty much the same values. At this point, I'm not sure what could be going on on your side. If you want to try producing some traces, we can help inspect them, looking for something weird. You can find some information about how to produce and better interpret traces in this blog post: http://blog.xen.org/index.php/2012/09/27/tracing-with-xentrace-and-xenalyze/ Perhaps you can share your VM config file and Dom0 configuration (basically, Xen and Linux boot command lines), to check whether there is something strange there. Also, you might have said this already (in which case I forgot), what versions of Xen and Linux are we talking about? I really am out of good ideas... George, any clue? Regards, Dario Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |