| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
MSVC complains:
error C4013: 'atomic_storeX' undefined; assuming extern returning int
atomic_storeX - is no longer defined. This patch adds back its implementation.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
C++ compiler cannot find matching function calls due to
unsupported implicit conversions. This change adds appropriate
explicit typecasts to match the existing function prototypes.
Signed-off-by: Shireesh Kumar Singh <shireeshkum@vmware.com>
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Co-authored-by: Sairam Venugopal <vsairam@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For some unclear and accidental reasons, the Windows 10 SDK
renamed _Interlocked* functions to _InlineInterlocked* (although the
documentation still points to the old form:
https://msdn.microsoft.com/en-us/library/191ca0sk.aspx).
This patch adds mappings for used functions.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Anand Kumar <kumaranand@vmware.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables atomics on x64 builds.
Reuse the atomics defined for x86 and add atomics for 64 bit reads/writes.
Before this patch the cmap test gives us:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations, batch size 1:
cmap insert: 20100 ms
cmap iterate: 2967 ms
batch search: 10929 ms
cmap destroy: 13489 ms
cmap insert: 20079 ms
cmap iterate: 2953 ms
cmap search: 10559 ms
cmap destroy: 13486 ms
hmap insert: 2021 ms
hmap iterate: 1162 ms
hmap search: 5152 ms
hmap destroy: 1158 ms
After this change we have:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations, batch size 1:
cmap insert: 2953 ms
cmap iterate: 267 ms
batch search: 2193 ms
cmap destroy: 2037 ms
cmap insert: 2909 ms
cmap iterate: 267 ms
cmap search: 2167 ms
cmap destroy: 2087 ms
hmap insert: 1853 ms
hmap iterate: 1086 ms
hmap search: 4395 ms
hmap destroy: 1140 ms
We should probably revisit this file and investigate it further to see if
we can squeeze more performance.
As a side effect fix tests on x64 because usage of `ovs-atomic-pthreads.h`
is currently broken.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Suggested-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
MSVC converts 64 bit read/writes into two instructions (uses 'mov' as
seen through cl //FAs). So there is a possibility that an interrupt can
make a 64 bit read/write non-atomic even when 8 byte aligned. So we cannot
use a simple assignment. Use a full memory barrier function instead.
Reported-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC does not support c11 style atomics for the C compiler.
Windows has different InterLocked* functions for different data
sizes. ovs-atomic-msvc.h maps the api in ovs-atomic.h (which is similar
to c11 atomics) to the available atomic functions in Windows. In some
cases, this causes compiler warnings about mismatched data sizes because
the generated code has 'if else' conditions on different data sizes and
proper casting is not possible.
In current OVS code base, we get one compiler warning through ovs-rcu.h
which says "‘void *’ differs in levels of indirection from LONGLONG."
This comes from the following in ovs-atomic-msvc.h for atomic_read64():
*(DST) = InterlockedOr64((int64_t volatile *) (SRC), 0);
when *DST is a void pointer (because InterLockedOr64 returns LONGLONG).
But this code path is only every hit for 64 bit data. So it should be safe to
disable the warning. (Any real bugs in api calls would hopefully be caught
while compiling on Linux using gcc/clang).
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
|
|
|
Before this change (i.e., with pthread locks for atomics on Windows),
the benchmark for cmap and hmap was as follows:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations:
cmap insert: 61070 ms
cmap iterate: 2750 ms
cmap search: 14238 ms
cmap destroy: 8354 ms
hmap insert: 1701 ms
hmap iterate: 985 ms
hmap search: 3755 ms
hmap destroy: 1052 ms
After this change, the benchmark is as follows:
$ ./tests/ovstest.exe test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations:
cmap insert: 3666 ms
cmap iterate: 365 ms
cmap search: 2016 ms
cmap destroy: 1331 ms
hmap insert: 1495 ms
hmap iterate: 1026 ms
hmap search: 4167 ms
hmap destroy: 1046 ms
So there is clearly a big improvement for cmap.
But the correspondig test on Linux (with gcc 4.6) yeilds the following:
./tests/ovstest test-cmap benchmark 10000000 3 1
Benchmarking with n=10000000, 3 threads, 1.00% mutations:
cmap insert: 3917 ms
cmap iterate: 355 ms
cmap search: 871 ms
cmap destroy: 1158 ms
hmap insert: 1988 ms
hmap iterate: 1005 ms
hmap search: 5428 ms
hmap destroy: 980 ms
So for this particular test, except for "cmap search", Windows and
Linux have similar performance. Windows is around 2.5x slower in "cmap search"
compared to Linux. This has to be investigated.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
[With a lot of inputs and help from Jarno]
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
|
