This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] Make bindresvport() function to multithread-safe
On 10/26/2012 03:29 AM, Carlos O'Donell wrote:
>>> Isn't there some internal lock type that's only 4 or 8 bytes rather
>>> than a whole pthread_mutex_t?
>>>
>>
>> Using __libc_lock_lock(NAME) is OK?
>> Just as patch v2: http://sourceware.org/ml/libc-alpha/2012-09/msg00507.html
>
> What is the performance difference between (a) Mutex i.e. v2 patch and
> (b) __thread solution?
>
The performance of __thread solution is better than Mutex.
The test result is as follows:
The test result of __thread solution, execute the test program with 500 times:
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
20,575 cache-misses ( +- 5.31% )
9,257,280 instructions # 0.00 insns per cycle ( +- 0.85% )
0.002695263 seconds time elapsed ( +- 3.35% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
21,258 cache-misses ( +- 5.56% )
9,091,239 instructions # 0.00 insns per cycle ( +- 0.83% )
0.002808214 seconds time elapsed ( +- 3.11% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
21,212 cache-misses ( +- 5.61% )
9,157,628 instructions # 0.00 insns per cycle ( +- 0.87% )
0.002642468 seconds time elapsed ( +- 2.88% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
21,225 cache-misses ( +- 6.00% )
9,204,583 instructions # 0.00 insns per cycle ( +- 0.85% )
0.002750918 seconds time elapsed ( +- 2.90% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
21,006 cache-misses ( +- 4.83% )
9,048,938 instructions # 0.00 insns per cycle ( +- 0.77% )
0.002707311 seconds time elapsed ( +- 2.81% )
The test result of mutex solution, execute the test program with 500 times:
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/nullbindresvport: Address already in use
bindresvport: Address already in use
...
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
17,919 cache-misses ( +- 4.79% )
7,277,944 instructions # 0.00 insns per cycle ( +- 0.44% )
0.002907394 seconds time elapsed ( +- 2.42% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
bindresvport: Address already in use
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
11,401 cache-misses ( +- 5.14% )
7,308,768 instructions # 0.00 insns per cycle ( +- 0.29% )
0.003194892 seconds time elapsed ( +- 1.45% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
bindresvport: Address already in use
bindresvport: Address already in use
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
16,076 cache-misses ( +- 7.09% )
7,356,625 instructions # 0.00 insns per cycle ( +- 0.41% )
0.003067836 seconds time elapsed ( +- 2.20% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
bindresvport: Address already in use
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
13,668 cache-misses ( +- 7.35% )
7,348,742 instructions # 0.00 insns per cycle ( +- 0.34% )
0.003057076 seconds time elapsed ( +- 2.17% )
# perf stat -r 100 -e cache-misses,instructions -- ./bindresvport_mul_test > /dev/null
bindresvport: Address already in use
bindresvport: Address already in use
bindresvport: Address already in use
Performance counter stats for './bindresvport_mul_test' (100 runs):
12,930 cache-misses ( +- 5.30% )
7,323,253 instructions # 0.00 insns per cycle ( +- 0.32% )
0.003140326 seconds time elapsed ( +- 1.96% )
> Is __thread significantly faster?
>
Yes, I think so:)
> Would you be happy with a mutex solution?
>
The two methods both can make bindresvport to multithread-safe,
but the performance of __thread solution is better than Mutex,
so I prefer __thread solution;)
Thanks.
--
Best Regards,
Peng
> Thank you for bearing with us here.
>
> Please understand that your issue touches on a question of policy and
> analysis that we have not had before.
>
> Cheers,
> Carlos.
>