Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <alpine.DEB.2.21.1809121623430.9957@nanos.tec.linutronix.de>
Date:   Wed, 12 Sep 2018 10:11:42 -0700
Cc:     Florian Weimer <fweimer@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Matt Rickard <matt@softrans.com.au>,
        Stephen Boyd <sboyd@kernel.org>,
        John Stultz <john.stultz@linaro.org>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEC1E2DC-2D89-4955-81FC-4EDCF3692214@amacapital.net>
References: <20180901015935.CCF0B18E20A9@virtux64.softrans.com.au> <CALCETrU4PzskO9pE6G4EkXNRRX3Mu7Vvjv1P8XgrfRMdgGDZSg@mail.gmail.com> <alpine.DEB.2.21.1809092159440.1402@nanos.tec.linutronix.de> <dde36e93-a21b-6223-8ffc-6dd11f687d38@redhat.com> <alpine.DEB.2.21.1809121616040.9957@nanos.tec.linutronix.de> <59403142-1073-3926-65dd-ac55ead357b9@redhat.com> <alpine.DEB.2.21.1809121623430.9957@nanos.tec.linutronix.de>
To:     Thomas Gleixner <tglx@linutronix.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Sep 12, 2018, at 7:29 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>=20
>> On Wed, 12 Sep 2018, Florian Weimer wrote:
>>> On 09/12/2018 04:17 PM, Thomas Gleixner wrote:
>>>> On Wed, 12 Sep 2018, Florian Weimer wrote:
>>>> Does this mean glibc can keep using a single vDSO entrypoint, the one w=
e
>>>> have today?
>>>=20
>>> We have no intention to change that.
>>=20
>> Okay, I was wondering because Andy seemed to have proposed just that.
>>=20
>>> But we surely could provide separate entry points as an extra to avoid a=

>>> bunch of conditionals.
>>=20
>> We could adjust to that, but the benefit would be long-term because it's a=
n
>> ABI change for glibc, and they tend to take a long time to propagate.
>>=20
>> But I must say that clock_gettime is an odd place to start.  I would have=

>> expected any of the type-polymorphic multiplexer interfaces (fcntl, ioctl=
,
>> ptrace, futex) to be a more natural starting point. 8-)
>=20
> Well, the starting point of this was to provide clock_tai support in the
> vdso. clock_gettime() in the vdso vs. the real syscall is a factor of 10 i=
n
> speed. clock_gettime() is a pretty hot function in some workloads.
>=20
> Andy then noticed that some conditionals could be avoided entirely by usin=
g
> a different entry point and offered one along with a 10% speedup. We don't=

> have to go there, we can.
>=20
> The multiplexer interfaces need much more surgery and talking about futex,=

> we'd need to sit down with quite some people and identify the things they
> actually care about before just splitting it up and keeping the existing
> overloaded trainwreck the same.
>=20

There=E2=80=99s also the issue of how much the speedup matters. For futex, m=
aybe a better interface saves 3ns, but a futex syscall is hundreds of ns. cl=
ock_gettime() is called at high frequency and can be ~25ns. Saving a few ns i=
s a bigger deal.=