lkml.org 
[lkml]   [2019]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 16/32] x86/vdso: Generate vdso{,32}-timens.lds
    From
    Date
    On 2/8/19 9:57 AM, Thomas Gleixner wrote:
    > On Thu, 7 Feb 2019, Rasmus Villemoes wrote:
    >
    > Cc: + Vincenzo, Will
    >
    >> On 06/02/2019 01.10, Dmitry Safonov wrote:
    >>> As it has been discussed on timens RFC, adding a new conditional branch
    >>> `if (inside_time_ns)` on VDSO for all processes is undesirable.
    >>> It will add a penalty for everybody as branch predictor may mispredict
    >>> the jump. Also there are instruction cache lines wasted on cmp/jmp.
    >>>
    >>> Those effects of introducing time namespace are very much unwanted
    >>> having in mind how much work have been spent on micro-optimisation
    >>> vdso code.
    >>>
    >>> Addressing those problems, there are two versions of VDSO's .so:
    >>> for host tasks (without any penalty) and for processes inside of time
    >>> namespace with clk_to_ns() that subtracts offsets from host's time.
    >>>
    >>> Unfortunately, to allow changing VDSO VMA on a running process,
    >>> the entry points to VDSO should have the same offsets (addresses).
    >>> That's needed as i.e. application that calls setns() may have already
    >>> resolved VDSO symbols in GOT/PLT.
    >>
    >> These (14-19, if I'm reading them right) seems to add quite a lot of
    >> complexity and fragility to the build, and other architectures would
    >> probably have to add something similar to their vdso builds.
    >
    > Yes and we really want to avoid that. The VDSO implementations are
    > pointlessly different accross the architectures and there is effort on the
    > way to consolidate them:
    >
    > https://lkml.kernel.org/r/20190115135539.24762-1-vincenzo.frascino@arm.com
    >
    > I talked to Vincenzo earlier this week and he's working on a new version of
    > that. The timens stuff wants to go on top of the consolidation otherwise we
    > end up with another set of pointlessly different and differently broken
    > VDSO variants.

    That looks awesome!
    I've missed the tread about it, will catch the details.

    Thanks much,
    Dmitry

    \
     
     \ /
      Last update: 2019-02-08 16:20    [W:4.246 / U:0.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site