From: Thomas Gleixner <tglx@linutronix.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: 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>
Subject: Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
Date: Wed, 12 Sep 2018 16:29:52 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1809121623430.9957@nanos.tec.linutronix.de> (raw)
In-Reply-To: <59403142-1073-3926-65dd-ac55ead357b9@redhat.com>
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 we
> > > have today?
> >
> > We have no intention to change that.
>
> Okay, I was wondering because Andy seemed to have proposed just that.
>
> > But we surely could provide separate entry points as an extra to avoid a
> > bunch of conditionals.
>
> We could adjust to that, but the benefit would be long-term because it's an
> ABI change for glibc, and they tend to take a long time to propagate.
>
> 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-)
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 in
speed. clock_gettime() is a pretty hot function in some workloads.
Andy then noticed that some conditionals could be avoided entirely by using
a different entry point and offered one along with a 10% speedup. We don't
have to go there, we can.
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.
Thanks,
tglx
next prev parent reply other threads:[~2018-09-12 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-01 1:59 [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO Matt Rickard
2018-09-01 3:39 ` Andy Lutomirski
2018-09-01 9:33 ` Florian Weimer
2018-09-01 17:37 ` Andy Lutomirski
2018-09-09 20:05 ` Thomas Gleixner
2018-09-10 10:38 ` Thomas Gleixner
2018-09-12 13:01 ` Florian Weimer
2018-09-12 14:17 ` Thomas Gleixner
2018-09-12 14:20 ` Florian Weimer
2018-09-12 14:29 ` Thomas Gleixner [this message]
2018-09-12 17:11 ` Andy Lutomirski
2018-09-13 8:07 ` Florian Weimer
2018-09-13 15:22 ` Andy Lutomirski
2018-09-13 19:07 ` Florian Weimer
2018-09-13 19:35 ` Andy Lutomirski
2018-09-13 19:53 ` Florian Weimer
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=alpine.DEB.2.21.1809121623430.9957@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=fweimer@redhat.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=matt@softrans.com.au \
--cc=sboyd@kernel.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.