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;
MIME-Version: 1.0
In-Reply-To: <20180901015935.CCF0B18E20A9@virtux64.softrans.com.au>
References: <20180901015935.CCF0B18E20A9@virtux64.softrans.com.au>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Fri, 31 Aug 2018 20:39:30 -0700
Message-ID: <CALCETrU4PzskO9pE6G4EkXNRRX3Mu7Vvjv1P8XgrfRMdgGDZSg@mail.gmail.com>
Subject: Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO
To:     Matt Rickard <matt@softrans.com.au>,
        Florian Weimer <fweimer@redhat.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Stephen Boyd <sboyd@kernel.org>,
        John Stultz <john.stultz@linaro.org>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: multipart/mixed; boundary="0000000000007c59390574c70f69"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--0000000000007c59390574c70f69
Content-Type: text/plain; charset="UTF-8"

(Hi, Florian!)

On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard <matt@softrans.com.au> wrote:
> Process clock_gettime(CLOCK_TAI) in vDSO.
> This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
>
>   nanoseconds
>  before after clockname
>    ---- ----- ---------
>     233    87 CLOCK_TAI
>      96    93 CLOCK_REALTIME
>      88    87 CLOCK_MONOTONIC

Are you sure you did this right?  With the clocksource set to TSC
(which is the only reasonable choice unless KVM has seriously cleaned
up its act), with retpolines enabled, I get 24ns for CLOCK_MONOTONIC
without your patch and 32ns with your patch.  And there is indeed a
retpoline in the disassembled output:

  e5:   e8 07 00 00 00          callq  f1 <__vdso_clock_gettime+0x31>
  ea:   f3 90                   pause
  ec:   0f ae e8                lfence
  ef:   eb f9                   jmp    ea <__vdso_clock_gettime+0x2a>
  f1:   48 89 04 24             mov    %rax,(%rsp)
  f5:   c3                      retq

You're probably going to have to set -fno-jump-tables or do something
clever like adding a whole array of (seconds, nsec) in gtod and
indexing that array by the clock id.

Meanwhile, I wrote the following trivial patch to add a
__vdso_clock_gettime_monotonic export.  It runs in 21ns, and I suspect
that the speedup is even a bit bigger when cache-cold because it
avoids some branches.  What do you all think?  Florian, do you think
glibc would be willing to add some magic to turn
clock_gettime(CLOCK_MONOTONIC, t) into
__vdso_clock_gettime_monotonic(t) when CLOCK_MONOTONIC is a constant?

--0000000000007c59390574c70f69
Content-Type: text/x-patch; charset="US-ASCII"; name="vclock_gettime_monotonic.patch"
Content-Disposition: attachment; filename="vclock_gettime_monotonic.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_jlivghyt0

ZGlmZiAtLWdpdCBhL2FyY2gveDg2L2VudHJ5L3Zkc28vdmNsb2NrX2dldHRpbWUuYyBiL2FyY2gv
eDg2L2VudHJ5L3Zkc28vdmNsb2NrX2dldHRpbWUuYwppbmRleCA5MWVkMWJiMmEzYmIuLjRmMjJl
OWNiOTdhNSAxMDA2NDQKLS0tIGEvYXJjaC94ODYvZW50cnkvdmRzby92Y2xvY2tfZ2V0dGltZS5j
CisrKyBiL2FyY2gveDg2L2VudHJ5L3Zkc28vdmNsb2NrX2dldHRpbWUuYwpAQCAtMzE5LDYgKzMx
OSwxNCBAQCBub3RyYWNlIGludCBfX3Zkc29fY2xvY2tfZ2V0dGltZShjbG9ja2lkX3QgY2xvY2ss
IHN0cnVjdCB0aW1lc3BlYyAqdHMpCiBpbnQgY2xvY2tfZ2V0dGltZShjbG9ja2lkX3QsIHN0cnVj
dCB0aW1lc3BlYyAqKQogCV9fYXR0cmlidXRlX18oKHdlYWssIGFsaWFzKCJfX3Zkc29fY2xvY2tf
Z2V0dGltZSIpKSk7CiAKK25vdHJhY2UgaW50IF9fdmRzb19jbG9ja19nZXR0aW1lX21vbm90b25p
YyhzdHJ1Y3QgdGltZXNwZWMgKnRzKQoreworCWlmIChsaWtlbHkoZG9fbW9ub3RvbmljKHRzKSAh
PSBWQ0xPQ0tfTk9ORSkpCisJCXJldHVybiAwOworCisJcmV0dXJuIHZkc29fZmFsbGJhY2tfZ2V0
dGltZShDTE9DS19NT05PVE9OSUMsIHRzKTsKK30KKwogbm90cmFjZSBpbnQgX192ZHNvX2dldHRp
bWVvZmRheShzdHJ1Y3QgdGltZXZhbCAqdHYsIHN0cnVjdCB0aW1lem9uZSAqdHopCiB7CiAJaWYg
KGxpa2VseSh0diAhPSBOVUxMKSkgewpkaWZmIC0tZ2l0IGEvYXJjaC94ODYvZW50cnkvdmRzby92
ZHNvLmxkcy5TIGIvYXJjaC94ODYvZW50cnkvdmRzby92ZHNvLmxkcy5TCmluZGV4IGQzYTJkY2U0
Y2ZhOS4uMjhlMjNjYmMwMmM5IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9lbnRyeS92ZHNvL3Zkc28u
bGRzLlMKKysrIGIvYXJjaC94ODYvZW50cnkvdmRzby92ZHNvLmxkcy5TCkBAIC0xNSw2ICsxNSwx
MSBAQAogICogVGhpcyBjb250cm9scyB3aGF0IHVzZXJsYW5kIHN5bWJvbHMgd2UgZXhwb3J0IGZy
b20gdGhlIHZEU08uCiAgKi8KIFZFUlNJT04geworCUxJTlVYXzQuMTkgeworCWdsb2JhbDoKKwkJ
X192ZHNvX2Nsb2NrX2dldHRpbWVfbW9ub3RvbmljOworCX07CisKIAlMSU5VWF8yLjYgewogCWds
b2JhbDoKIAkJY2xvY2tfZ2V0dGltZTsK
--0000000000007c59390574c70f69--