l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SUN TLS vs. GNU TLS (was Re: ELF TLS ABI vs L4 ABI)


From: Espen Skoglund
Subject: SUN TLS vs. GNU TLS (was Re: ELF TLS ABI vs L4 ABI)
Date: Thu, 18 Nov 2004 18:47:52 +0100

[Marcus Brinkmann]
> [TS] Support the ELF TLS ABI, SUN variant.
>      (%gs:0 contains thread pointer)
> [TG] Support the ELF TLS ABI, GNU variant.
>      (%gs is a 4GB segment with thread pointer as base address)

> [...]

> [SS] Small spaces rely on segment limits for protection.
> Considering that applications for small spaces include performance
> critical parts like the user-space scheduler, and irq
> handlers/drivers (fast-ethernet?), we are sceptical if the ELF TLS
> optimization of [TG] over [TS] is worth this.

Has anyone ever done any empirical analysis of the performance
"advantages" of SUN ELF TLS over GNU ELF TLS?  Surely something like
this must exist in order to motive GNU TLS in the first place.

Here are some things to consider when comparing the two approaches
(both performance and functionality wise):

  o Accessing something through the %gs segment requires a segment
    override prefix to the instruction.  I'm not sure if this causes
    any overhead (except for the larger instruction size) to the
    execution on various CPUs, but it might.

  o For GNU TLS, any string operation with the destination in the TLS
    will require the %es segment selector to be reloaded first.

  o For SUN TLS, if there typically are several consececutive TLS
    accesses one need not read out the TLS location from %gs:0 on each
    access; only on the first access.

  o For GNU TLS, since the TLS is accessed through %gs one *must*
    program all TLS accesses in assembly.  That is, one can not just
    tell the compiler that the TLS is located on location so and so,
    and let the compiler itself handle all the memory accesses.  This
    means that 1) TLS related code becomes harder to manage, and 2)
    the compiler is unable to optimize the accesses to the TLS (e.g.,
    by cache prefetching, memory access reordering, etc.).

As I said, I have no idea what impact all this has on real workloads.
All I can say is that the last point seems to greatly disfavour the
GNU TLS approach (as you said yourself, glibc already seems to be
really badly infested with hardcoded %gs accesses).

        eSk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]