This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Machine maintainers, please test your machines.
- From: Torvald Riegel <triegel at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Chris Metcalf <cmetcalf at ezchip dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at suse dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Tue, 27 Jan 2015 12:10:26 +0100
- Subject: Re: glibc 2.21 - Machine maintainers, please test your machines.
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb> <54C5094A dot 8060300 at ezchip dot com> <54C51D94 dot 6030007 at ezchip dot com> <1422276280 dot 29655 dot 91 dot camel at triegel dot csb> <54C6A1DD dot 4020004 at ezchip dot com> <1422305739 dot 29655 dot 144 dot camel at triegel dot csb> <54C6CDD2 dot 5000608 at ezchip dot com> <CAMe9rOoNWFczhGJYkKVHiRnRenJPFFt7BZRpM=71fYxtatasvg at mail dot gmail dot com>
On Mon, 2015-01-26 at 16:17 -0800, H.J. Lu wrote:
> What is the drawback with 32-bit atomics for x32? If there is no real
> advantage for 64-bit atomics, x32 will use 32-bit atomics. If x32 needs
> to use 64-bit atomics, I need to investigate which way to go.
>
64b atomics do not give any advantage in sem_post nor on the fast path
of sem_wait (ie, if sem_wait does not use a futex to block, but just can
grab a token, or spin-waits (not implemented yet)).
64b atomics allows for a more efficient sem_wait slow path; that is,
when we use a futex to block. In a nutshell, we don't need to do what's
in sem_waitcommon.c:__sem_wait_32_finish() and another atomic
read-modify-write operation before the futex_wait.
The additional overhead around the futex_wait call is not a really big
problem I would say, as futexes are relatively slow anyway and we
shouldn't use them for short periods of waiting (that's where the
missing spin-waiting would come into play).
The disadvantage that the slow path can have however is potentially
decreased scalability, because the additional atomic ops might slow down
other threads. But I wouldn't consider this a really critical issue,
especially not once we add some spin-waiting. There could also be
pathological situations in which we have a high rate of sem_wait /
sem_post calls, and the sem_wait's can't agree on who's last, so we
might get lots of unnecessary futex_wake calls in
__sem_wait_32_finish().
- References:
- glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.
- Re: glibc 2.21 - Machine maintainers, please test your machines.