This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A per-user or per-application

On 02/08/2016 10:29 PM, Siddhesh Poyarekar wrote:
> On Mon, Feb 08, 2016 at 03:14:08PM -0500, Carlos O'Donell wrote:
>> The downside is that the user has no control of this cache and
>> would need administrative intervention for help accelerating their
>> application. Consider that you bought time on a cluster of machines,
>> and now to run your app you're making the user interact with the sysadmin
>> to install new filters and run ldconfig on every node? It won't scale
>> (from a human perspective).
>> With a per-user/per-proces cache say in ~/, the user could
>> prime the cache themselves after setting up their application with
>> bundled libraries and have it work as expected, but accelerated lookups
>> without lots of stat/getdents in $HOME.
>> Does that counter-argument make sense for why the cache could be
>> under user control? It means the data needs to be inspected carefully
>> though.
> Sure, but a similar effect could also be achieved using
> LD_LIBRARY_PATH in ~/.bashrc.

Not similar enough from a performance perspective.

If you have 15 paths in LD_LIBRARY_PATH, they each need to be searched
in order to find the DSOs required in the last path entry. If you had
a per-user cache it's a single cache lookup and an mmap. There is no
traversal required of any filesystem if you get a hit in the cache.

Isn't that much better?

All of the cache machinery is there, we just don't have a per-user


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]