Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Jun 2017 13:05:35 -0400
From: Rich Felker <>
Subject: Re: [PATCH 4/8] determine the existence of private futexes at
 the first thread creation

On Tue, Jun 20, 2017 at 10:35:28PM +0200, Jens Gustedt wrote:
> The current strategie to deal with kernels that don't implement private
> futexes is to
>  - test if the call works with FUTEX_PRIVATE
>  - fallback to a call without if it doesn't
> This forces an overhead for both sides, Linux'es with and without private
> futexes. For those with, it adds a superflouous branch instruction to all
> calls. For those without, it add the whole call overhead of a syscall.

This was intentional, the idea being that a 100% predictable branch in
a path where a syscall is being made anyway is much less expensive
than a GOT address load that gets hoisted all the way to the top of
the function and affects even code paths that don't need to make the
syscall. Whether it was a choice that makes sense overall, I'm not
sure, but that was the intent.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.