On 09/13/2018 09:35 PM, Andy Lutomirski wrote:
Somewhat special, yes, but not overly so, and not in the type-polymorphic
sense. We can't give direct access of the vDSO implementation to applications
because the kernel does not know about the userspace errno variable. We do
that for time on
> On Sep 13, 2018, at 12:07 PM, Florian Weimer wrote:
>
> On 09/13/2018 05:22 PM, Andy Lutomirski wrote:
>>> On Sep 13, 2018, at 1:07 AM, Florian Weimer wrote:
>>>
>>> On 09/12/2018 07:11 PM, Andy Lutomirski wrote:
> The multiplexer interfaces need much more surgery and talking about fut
On 09/13/2018 05:22 PM, Andy Lutomirski wrote:
On Sep 13, 2018, at 1:07 AM, Florian Weimer wrote:
On 09/12/2018 07:11 PM, Andy Lutomirski wrote:
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 th
> On Sep 13, 2018, at 1:07 AM, Florian Weimer wrote:
>
> On 09/12/2018 07:11 PM, Andy Lutomirski wrote:
>>> 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 ju
On 09/12/2018 07:11 PM, Andy Lutomirski wrote:
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 sa
> On Sep 12, 2018, at 7:29 AM, Thomas Gleixner 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
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
On 09/12/2018 04:17 PM, Thomas Gleixner wrote:
On Wed, 12 Sep 2018, Florian Weimer wrote:
On 09/09/2018 10:05 PM, Thomas Gleixner wrote:
See the patch below. It's integrating TAI without slowing down everything
and it definitely does not result in indirect calls.
On a HSW it slows down clock_g
On Wed, 12 Sep 2018, Florian Weimer wrote:
> On 09/09/2018 10:05 PM, Thomas Gleixner wrote:
> > See the patch below. It's integrating TAI without slowing down everything
> > and it definitely does not result in indirect calls.
> >
> > On a HSW it slows down clock_gettime() by ~0.5ns. On a SKL I ge
On 09/09/2018 10:05 PM, Thomas Gleixner wrote:
See the patch below. It's integrating TAI without slowing down everything
and it definitely does not result in indirect calls.
On a HSW it slows down clock_gettime() by ~0.5ns. On a SKL I get a speedup
by ~0.5ns. On a AMD Epyc server it's 1.2ns spee
On Sun, 9 Sep 2018, Thomas Gleixner wrote:
> #ifdef BUILD_VDSO32_64
> typedef u64 gtod_long_t;
> #else
> typedef unsigned long gtod_long_t;
> #endif
> +
> +struct vgtod_ts {
> + gtod_long_t sec;
and actually this wants to become u64 unconditionally as we need to provide
the full secon
On Fri, 31 Aug 2018, Andy Lutomirski wrote:
> (Hi, Florian!)
>
> On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard 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
> >
On Sat, Sep 1, 2018 at 2:33 AM, Florian Weimer wrote:
> On 09/01/2018 05:39 AM, Andy Lutomirski wrote:
>>
>> 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?
On 09/01/2018 05:39 AM, Andy Lutomirski wrote:
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?
What's the goal here? Turn the indirect call/conditional jump/indir
(Hi, Florian!)
On Fri, Aug 31, 2018 at 6:59 PM, Matt Rickard 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
> - -
> 23387 CLOCK_TAI
> 969
Process clock_gettime(CLOCK_TAI) in vDSO.
This makes the call about as fast as CLOCK_REALTIME and CLOCK_MONOTONIC:
nanoseconds
before after clockname
- -
23387 CLOCK_TAI
9693 CLOCK_REALTIME
8887 CLOCK_MONOTONIC
Signed-off-by: Matt Rickard
---
arc
16 matches
Mail list logo
