From: Jonathan Wakely <jwakely@redhat.com>
To: Torvald Riegel <triegel@redhat.com>
Cc: Mike Crowe <mac@mcrowe.com>,
libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait
Date: Fri, 12 Jan 2018 14:50:00 -0000 [thread overview]
Message-ID: <20180112144947.GE24454@redhat.com> (raw)
In-Reply-To: <1515763080.4439.129.camel@redhat.com>
On 12/01/18 14:18 +0100, Torvald Riegel wrote:
>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.
I don't think we currently have a documented minimum, although there
is an implied one, which I guess is 2.6.0 ... I can't think of
anything else that places requirements on the kernel. Apart from NPTL
we use SYS_futex and SYS_clock_gettime, but there are alternative code
paths for both of those.
>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.
Agreed. Gthreads is the cause of a few problems for libstdc++.
>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.
We document that we require glibc 2.3, but that is ancient. It's
possible we've unintentionally introduced an implicit requirement on a
newer version.
next prev parent reply other threads:[~2018-01-12 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-07 20:55 [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required Mike Crowe
2018-01-07 20:55 ` [PATCH 1/5] Improve libstdc++-v3 async test Mike Crowe
2018-01-09 14:32 ` Jonathan Wakely
2018-01-07 20:55 ` [PATCH 3/5] libstdc++ futex: Support waiting on std::chrono::steady_clock directly Mike Crowe
2018-01-07 20:55 ` [PATCH 4/5] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock Mike Crowe
2018-01-07 20:55 ` [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait Mike Crowe
2018-01-09 13:56 ` Jonathan Wakely
2018-01-09 17:54 ` Mike Crowe
2018-01-12 13:21 ` Torvald Riegel
2018-01-12 14:50 ` Jonathan Wakely [this message]
2018-01-12 17:57 ` Joseph Myers
2018-01-07 20:55 ` [PATCH 5/5] Extra async tests, not for merging Mike Crowe
2018-01-09 14:44 ` [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required Jonathan Wakely
2018-01-13 15:34 ` Torvald Riegel
2018-01-14 16:19 ` Mike Crowe
2018-01-14 20:51 ` Mike Crowe
2018-02-14 16:32 ` Mike Crowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180112144947.GE24454@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=mac@mcrowe.com \
--cc=triegel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).