Hi Ben,
Thanks for pointing this out.
On 08/07/14 18:10, Ben Pfaff wrote:
Hi Anoob. Guru noticed (and I confirmed) that recent versions of Open
vSwitch on master suffer a little, performance-wise, on XenServer. In
particular, the cmap code doesn't perform well. In the OVS testsuite,
the cmap test takes about a minute to run on XenServer, versus about 2.5
seconds with other distributions.
cuckoo hashing was introduced recently and I don't think we (ovs-dev)
have any plans to merge cuckoo hashing to 2.1.x. At XenServer we are
using 2.1.x and no plans to move further for the current release. So
XenServer is safe w.r.t to cmap. But there are other places which uses
atomic primitives which might be impacted by the version of GCC we are
using.
I think that the difference is the GCC version. The XenServer DDK has
GCC 4.1, I believe. On that version of GCC, OVS has to fall back to a
less flexible set of atomic memory access primitives than available on
GCC 4.7 and later. I think that GCC must be generating extra CPU
synchronization instructions that are not actually needed, making the
generated code very expensive.
One solution would be to use a newer GCC version on XenServer, but I'm
reluctant to do that because it would mean we'd have to install new
software into all the Xen DDK targets we use, which is a large number.
Another solution would be to open-code CPU synchronization instructions
where necessary in the atomic implementation for GCC pre-4.7. That
would probably be easier, but it's a little tricky (in practice we'd
probably need a new atomic implementation for x86-on-GCC-pre4.7 and
keep the current one for other-CPUs-on-GCC-pre4.7).
Yes, that is correct. For the current planned release we would be using
GCC 4.1.2 and there are no plans to change the version of GCC as we are
almost at the end of development phase. I would prefer the later
approach of open-coding CPU synchronization instructions. I will do some
experiments with 2.1.2 to see how bad these primitives are.
Any thoughts?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev