This is the mail archive of the
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: Florian Weimer <fweimer at redhat dot com>
- To: carlos at redhat dot com
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 8 Feb 2016 20:10:08 +0100
- Subject: Re: A per-user or per-application ld.so.cache?
- Authentication-results: sourceware.org; auth=none
- References: <56B8E105 dot 8030906 at redhat dot com>
On 02/08/2016 07:40 PM, Carlos O'Donell wrote:
> Under what conditions might it make sense to implement
> a per-user ld.so.cache?
> At Red Hat we have some customers, particularly in HPC,
> which deploy quite large applications across systems that
> they don't themselves maintain. In this case the given
> application could have thousands of DSOs. When you load
> up such an application the normal search paths apply
> and that's not very optimal.
Are these processes short-lived?
Is symbol lookup performance an issue as well?
What's the total size of all relevant DSOs, combined? What does the
directory structure look like?
Which ELF dynamic linking features are used?
Is the bulk of those DSOs pulled in with dlopen, after the initial
dynamic link? If yes, does this happen directly (many DSOs dlopen'ed
individually) or indirectly (few of them pull in a huge cascade of
If the processes are not short-lived and most of the DSOs are loaded
after user code has started executing, I doubt an on-disk cache is the