Messages in this thread | | | Subject | Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO | From | Andy Lutomirski <> | Date | Wed, 12 Sep 2018 10:11:42 -0700 |
| |
> On Sep 12, 2018, at 7:29 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > >> 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. >
There’s also the issue of how much the speedup matters. For futex, maybe a better interface saves 3ns, but a futex syscall is hundreds of ns. clock_gettime() is called at high frequency and can be ~25ns. Saving a few ns is a bigger deal.
| |