[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] CAP and performance problem
On Tue, May 21, 2013 at 11:41 AM, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote: > On Tue, May 21, 2013 at 10:02 AM, Massimo Canonico <mex@xxxxxxxxxxxx> wrote: >> Hi, >> 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? > > How many vcpus do you have? > > I'm not sure the CAP stuff actually does anything sensible with > multiple cpus -- e.g., a VM with 2 vcpus maxed out will typically > actually get 200%, so will a CAP force both of them to get only 25% > each? > > The other possibility if you've got multiple vcpus is that you're > running into something I call "concurrency hazard": if one vcpu grabs > a spinlock and then is paused in order to enforce the cap, and another > vcpu tries to grab that spinlock, it will just spin until the first > vcpu manages to wake up and release it again. Sorry, meant to add: if you have more than one vcpu and you want to limit the cpu footprint, you're much better off halving the number of vcpus rather than giving each vcpu only 50% of a cpu. I gave a presentation on why here, if you're interested: http://www.citrix.com/tv/#videos/2930 -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |