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

Bug#431143: marked as done (libc6: ldconfig mmaps every library file whether it needs and update or not)

Your message dated Tue, 26 Feb 2008 22:22:11 +0100
with message-id <20080226212211.GA30434@volta.aurel32.net>
and subject line Re: Bug#431143: libc6: ldconfig mmaps every library file whether it needs and update or not
has caused the Debian Bug report #431143,
regarding libc6: ldconfig mmaps every library file whether it needs and update or not
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
431143: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431143
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.5-11
Severity: normal

Since #374945 has been closed and indeed archived, the patch fixing it
has been backed out.  I can't reopen that bug, but please consult
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374945.html for the
background information.

Essentially, ldconfig is run after every lib*.deb package is updated
in a dpkg run.  This can be hundreds of times in a move between debian
releases.  After each time ldconfig is run, on machines with less than
about 256MB, everything ldconfig dealt with has long been purged out
of filesystem cache by the time the next package comes along to run
ldconfig (on my 256MB machine, dpkg can be updating two library
packages successively, and nothing remains in cache by the time the
second library has installed its files and runs its postinst scripts).
So when everyone claims that it's not so bad that ldconfig is run
multiple times, because the second time is always much quicker, they
are operating under the hidden false assumption that everyone is
blessed with a machine with more than 256MB.  They didn't even become
universally common until about a year ago in these quarters and I
still see plenty of new machines with only 256MB on dell's website.

Now the cause of the problem is that for every ldconfig call that
ought to just update the symlinks of the one package in question, and
perhaps update the ld.so.cache file (although on a quick glance
through an strace call to a typical program, that appears entirely
unnecessary), an open(), fstat64(), and crucially, a mmap() and hence
presumably, slurping in some of that file's contents, is done on every
file in every lib directory.  All of that, for every file, has to fit
in cache, if the second invocation to ldconfig a few seconds later is
going to take any less time than the first.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.20-1-686 (SMP w/1 CPU core)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1                 1:4.2-20070627-1 GCC support library

libc6 recommends no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.7-1

On Sun, Jul 01, 2007 at 09:58:01PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 30, 2007 at 03:14:14PM +1000, Tim Connors wrote:
> > Now the cause of the problem is that for every ldconfig call that
> > ought to just update the symlinks of the one package in question, and
> > perhaps update the ld.so.cache file (although on a quick glance
> > through an strace call to a typical program, that appears entirely
> > unnecessary), an open(), fstat64(), and crucially, a mmap() and hence
> > presumably, slurping in some of that file's contents, is done on every
> > file in every lib directory.  All of that, for every file, has to fit
> > in cache, if the second invocation to ldconfig a few seconds later is
> > going to take any less time than the first.
> 
> Conveniently, SuSE just implemented a secondary cache for ldconfig
> that reduces the cost of this to almost nothing (see libc-alpha
> archives for June).
> 

This patch is present in glibc 2.7. Closing the bug.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: