This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait
On Tue, 2018-01-09 at 17:54 +0000, Mike Crowe wrote:
> On Tuesday 09 January 2018 at 13:50:54 +0000, Jonathan Wakely wrote:
> > On 07/01/18 20:55 +0000, Mike Crowe wrote:
> > > The futex system call supports waiting for an absolute time if
> > > FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two
> > > benefits:
> > >
> > > 1. The call to gettimeofday is not required in order to calculate a
> > > relative timeout.
> > >
> > > 2. If someone changes the system clock during the wait then the futex
> > > timeout will correctly expire earlier or later. Currently that only
> > > happens if the clock is changed prior to the call to gettimeofday.
> > >
> > > According to futex(2), support for FUTEX_CLOCK_REALTIME was added in the
> > > v2.6.28 Linux kernel and FUTEX_WAIT_BITSET was added in v2.6.25. There is
> > > no attempt to detect the kernel version and fall back to the previous
> > > method.
> >
> > I don't think we can require a specific kernel version just for this.
>
> What is the minimum kernel version that libstdc++ requires? Since it's
> already relying on NPTL it can't go back earlier than v2.6, but I suppose
> that's a while before v2.6.28.
I'm not aware of any choice regarding this, but Jonathan will know for
sure.
Generally, I think choosing a minium kernel version might be helpful, in
particular if we want to optimize more often specifically for Linux
environments; this may become more worthwhile in the future, for example
when we look at new C++ features such as parallel algorithms, or
upcoming executors.
The gthreads abstraction may is a nice goal, but we can benefit a lot
from knowing what the underlying platform really is.
Another option might be to require a minimum glibc version on Linux, and
build libstdc++ for that. That would yield a minimum kernel version as
well, and we may can make use of other things in return such as syscall
wrappers.
> > What happens if you use those bits on an older kernel, will there be
> > an ENOSYS error? Because that would allow us to try the new form, and
> > fallback to the old.
>
> Glibc's nptl-init.c calls
>
> futex(.., FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME | FUTEX_PRIVATE_FLAG, ..)
>
> and sets __have_futex_clock_realtime based on whether it gets ENOSYS back
> or not so it looks like it is possible to determine whether support is
> available.
>
> The only such check I can find in libstdc++ is in filesystem/std-ops.cc
> fs::do_copy_file which can try sendfile(2) on each invocation but then
> automatically falls back to copying by steam. In that case, the overhead of
> the potentially-failing sendfile system call is small compared to copying
> the file.
>
> Doing such a check in _M_futex_wait_until means one system call if
> FUTEX_CLOCK_REALTIME is supported, but three system calls if it is not
> supported. If we found a way to cache the answer in a thread-safe and cheap
> manner then this could be avoided.
>
> Do you think it's worth trying to cache whether FUTEX_CLOCK_REALTIME is
> available?
It may be worth caching that, given how simple this can be: Just add a
global atomic variable whose initial value means trying the most recent
syscall op, and set that to some other value that indicates an older
kernel. Then check the value before attempting the syscall. Can all be
relaxed atomic accesses because it's essentially just a best-effort
optimization.
Performance-wise, the trade-off is between an additional atomic load for
new kernels vs. one additional syscall for older kernels. Given that we
need the fallback for old kernels anyway unless we select a minimum
version, I guess doing the caching makes sense. The syscalls are on the
slow paths anyway.