Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5541701imm; Wed, 12 Sep 2018 07:31:01 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdac3ZGj/zzRgh/tqMcNWpYIPUCLJji4mt4pQPamgZYASAPbMh7jUM4L38r9rMFk5SMXKjpT X-Received: by 2002:a62:5f82:: with SMTP id t124-v6mr2665523pfb.223.1536762661402; Wed, 12 Sep 2018 07:31:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536762661; cv=none; d=google.com; s=arc-20160816; b=CFbEq8aYpLj11hSvj1MR8amnDmR6S5xLO0m198OaUOwQ5rwI9txVm/lt+TdvY3EmuW d0TR8J6bNY2BA2VlpbnBDmWhWZ8/tVGWdA1T5l8J115a7F6wXj6xsWDrbA3JFrPYsMuI 3f479svcTES+afoQKLoM+EswAJqYMtUqUPZ9S8LKU5GnKN8Y1cwOZjmnPCZ/KW1PSQE2 +wgqe3fLzBOTyX/UUdO6G1BO7vyRWcQmy4Y4Jpbcxq9pFMJWimKlGC+hRjRYtzkG3jkf Sdm5Pviny2Qk3vHrilDhw+wMkzLnpEj4ldSHEDYBHy7hDJi0bT12ropbuZU6N2n8Tb8o D4+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=M2D6X/NUZQU32zcT5bOuYFflRkO/zH5AzMe7pePZu1o=; b=Od+M/gvwlhT0vDGgZc2fOdWggus/Q3Sbq0y0TMQ2RRqy9tv9+cKNGR3EUyYHg5MhN7 Ct7g37j2GCRw5rk9sbgNUSN0hdR1xRl026gUn6XXXDhEeGAvQ4NVrzrG3Wj9hh/zcVbr fx+r/h6zLh8IQT+QjTPk78iBREJwHwW8g+B9Dt/EWIUEVBlSM8qMm+sWO2vaT+6R0PMC 1vmoF0ohNmwh10f63cS7RtMb+cd3efevHTgCKK7do1uGWk1d2IHtX6YqRe8N1n26LqnY Jv2pxwzonTSWq7LhqankPFiXP3AH//x9ZkSz2oolcFyMXqoaJVTrNamF3DGHcuxhhEZl DHVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v71-v6si1158340pgd.601.2018.09.12.07.30.39; Wed, 12 Sep 2018 07:31:01 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727670AbeILTfG (ORCPT + 99 others); Wed, 12 Sep 2018 15:35:06 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:44111 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726672AbeILTfG (ORCPT ); Wed, 12 Sep 2018 15:35:06 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g069Q-00025P-Dp; Wed, 12 Sep 2018 16:29:52 +0200 Date: Wed, 12 Sep 2018 16:29:52 +0200 (CEST) From: Thomas Gleixner To: Florian Weimer cc: Andy Lutomirski , Matt Rickard , Stephen Boyd , John Stultz , X86 ML , LKML Subject: Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO In-Reply-To: <59403142-1073-3926-65dd-ac55ead357b9@redhat.com> Message-ID: References: <20180901015935.CCF0B18E20A9@virtux64.softrans.com.au> <59403142-1073-3926-65dd-ac55ead357b9@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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