Re: glibc 2.21 - Machine maintainers, please test your machines.

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Jan 27, 2015 at 3:10 AM, Torvald Riegel <triegel@redhat.com> wrote:
> 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.

In that case, I'd like to use 64-bit atomics in sem_wait slow path
for x32 and 32-bit atomics elsewhere.  I will pay potential extra
memory bus cycle on slow path.

> 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().
>



-- 
H.J.