[Xenomai-help] dynamic loader latencies

[Xenomai-help] dynamic loader latencies

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

The Linux ELF dynamic linker/loader ld-linux.so uses a "lazy" model by
default, and defers symbol resolution, shared object resolution to the time
when the symbol is first referenced.  This sounds like a large latency
threat to dynamically linked RT applications running in primary mode. Can
this happen, or is this unlikely?

If this is a latency risk, the only solutions I know of are:

1) Statically link all RT applications

2) Invoke all dynamically linked applications with LD_BIND_NOW=1 environment
to force the dynamic loader to resolve all  symbols  at program startup

3) Link dynamic applications with "-z now" GNU ld option to effect same as
2) above.

Comments?

thanks,
Jeff

[-- Attachment #2: Type: text/html, Size: 900 bytes --]

[Xenomai-help] Fwd: dynamic loader latencies

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Bumping this post again in hopes of eliciting comments ...

Jeff

---------- Forwarded message ----------
From: Jeff Weber <jwamsc@domain.hid>
Date: Fri, Aug 26, 2011 at 11:34 AM
Subject: dynamic loader latencies
To: Xenomai Help <xenomai@xenomai.org>


The Linux ELF dynamic linker/loader ld-linux.so uses a "lazy" model by
default, and defers symbol resolution, shared object resolution to the time
when the symbol is first referenced.  This sounds like a large latency
threat to dynamically linked RT applications running in primary mode. Can
this happen, or is this unlikely?

If this is a latency risk, the only solutions I know of are:

1) Statically link all RT applications

2) Invoke all dynamically linked applications with LD_BIND_NOW=1 environment
to force the dynamic loader to resolve all  symbols  at program startup

3) Link dynamic applications with "-z now" GNU ld option to effect same as
2) above.

Comments?

thanks,
Jeff

[-- Attachment #2: Type: text/html, Size: 1396 bytes --]

Re: [Xenomai-help] Fwd: dynamic loader latencies

[Gilles Chanteperdrix]

On 08/29/2011 03:26 PM, Jeff Weber wrote:
> Bumping this post again in hopes of eliciting comments ...
> 
> Jeff
> 
> ---------- Forwarded message ----------
> From: Jeff Weber <jwamsc@domain.hid>
> Date: Fri, Aug 26, 2011 at 11:34 AM
> Subject: dynamic loader latencies
> To: Xenomai Help <xenomai@xenomai.org>
> 
> 
> The Linux ELF dynamic linker/loader ld-linux.so uses a "lazy" model by
> default, and defers symbol resolution, shared object resolution to the time
> when the symbol is first referenced.  This sounds like a large latency
> threat to dynamically linked RT applications running in primary mode. Can
> this happen, or is this unlikely?
> 
> If this is a latency risk, the only solutions I know of are:
> 
> 1) Statically link all RT applications
> 
> 2) Invoke all dynamically linked applications with LD_BIND_NOW=1 environment
> to force the dynamic loader to resolve all  symbols  at program startup
> 
> 3) Link dynamic applications with "-z now" GNU ld option to effect same as
> 2) above.
> 
> Comments?

The best way to be sure is to run some benches. I never run such
benches, so, cannot answer.

-- 
					    Gilles.

Re: [Xenomai-help] dynamic loader latencies

[Philippe Gerum]

On Fri, 2011-08-26 at 11:34 -0500, Jeff Weber wrote:
> The Linux ELF dynamic linker/loader ld-linux.so uses a "lazy" model by
> default, and defers symbol resolution, shared object resolution to the
> time when the symbol is first referenced.  This sounds like a large
> latency threat to dynamically linked RT applications running in
> primary mode. Can this happen, or is this unlikely?

Good question, I never actually measured this over an application
mapping shared libs which would consist of a large number of routines
called over time.

I would tend to think that ld.so's symbol lookup routine might represent
the highest risk for significant latency, if any, because all the rest,
i.e. GOT, PLT and the code itself should have been read in and processed
at program init, either by ld.so or as a result of mlocking the program.

Running the trampoline code from the PLT and fixing up the GOT with the
indirect jump address after symbol resolution should not entail
significant latency either, so the real issue, if any, might be
introduced by the lookup code actually resolving the symbols. I would
think that all the data is already there, available to ld.so for this
operation, and the ELF format mandates that dynamic symbol names be
hashed for fast retrieval. However, I may be wrong, this needs to be
verified.

> 
> 
> If this is a latency risk, the only solutions I know of are:
> 
> 
> 1) Statically link all RT applications
> 
> 
> 2) Invoke all dynamically linked applications with LD_BIND_NOW=1
> environment to force the dynamic loader to resolve all  symbols  at
> program startup
> 
> 
> 3) Link dynamic applications with "-z now" GNU ld option to effect
> same as 2) above.
> 
> 
> Comments?
> 

In short, my understanding is that we should not see significant extra
latency, unless ld.so does on demand loading of portions of the ELF
tables/sections it needs for symbol resolution, instead of loading these
tables at program init. This seems unlikely though.

> 
> thanks,
> Jeff
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.