From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <email@example.com>,
Tom Stellard <firstname.lastname@example.org>
Cc: Nick Desaulniers <email@example.com>,
Masahiro Yamada <firstname.lastname@example.org>,
Nathan Chancellor <email@example.com>,
"Linux Kernel Mailing List" <firstname.lastname@example.org>,
Fangrui Song <email@example.com>,
Serge Guelton <firstname.lastname@example.org>,
Sylvestre Ledru <email@example.com>
Subject: RE: Very slow clang kernel config ..
Date: Sat, 1 May 2021 21:58:55 +0000 [thread overview]
Message-ID: <4b77489c05f6459ead7233c3fb69f61e@AcuMS.aculab.com> (raw)
From: Linus Torvalds
> Sent: 01 May 2021 17:32
> On Fri, Apr 30, 2021 at 8:33 PM Tom Stellard <firstname.lastname@example.org> wrote:
> > Yes, it's intentional. Dynamic linking libraries from other packages is
> > the Fedora policy, and clang and llvm are separate packages (in Fedora).
> Side note: I really wish Fedora stopped doing that.
> Shared libraries are not a good thing in general. They add a lot of
> overhead in this case, but more importantly they also add lots of
> unnecessary dependencies and complexity, and almost no shared
> libraries are actually version-safe, so it adds absolutely zero
It's 'swings and roundabouts'...
I used a system where the libc.so the linker found was actually
an archive library, one member being libc.so.1.
The function that updated utmp and utmpx (last login details)
was in the archive part.
This code had incorrect locking and corrupted the files.
While the fix was easy, getting in 'installed' wasn't because all
the programs that used it needed to be relinked - hard when some
where provided as commercial binaries by 3rd parties.
I've also done some experiments with the mozilla web browser.
This loaded about 30 libraries at program startup.
The elf symbol hashing rules don't help at all!
Every symbol gets looked for in every library (often checking
for a non-weak symbol having found a weak definition).
So the hash of the symbol is calculated.
It is remaindered by the hash table size and the linked list scanned.
Now the hash table size is the prime below the power of 2 below
the number of symbols (well was when I did this).
So the average hash chain has about 1.5 entries.
With 30 libraries this is ~45 string compares.
If all the strings start with similar strings (C++classes)
then the strcmp() are quite long.
I played around with the hash table size.
It really didn't matter whether it was a prime or not.
For libc the distribution was always horrid - with some
quite long hash chains.
Making the hash table larger than the number of symbols
(perhaps 2 powers of 2 above) would be more likely to
make the hash hit an empty list - and skip all the strcmp().
The other 'trick' was a rewrite of the dynamic loader to
generate a single symbol table that contained all the symbols
of all the libraries loaded at program startup.
Process the libraries in the right order and this is easy.
That made a considerable improvement to program startup.
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-05-01 22:07 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 21:53 Very slow clang kernel config Linus Torvalds
2021-04-30 0:19 ` Nick Desaulniers
2021-04-30 2:22 ` Nick Desaulniers
2021-05-01 0:19 ` Nick Desaulniers
2021-05-01 0:23 ` Nick Desaulniers
2021-05-01 0:25 ` Nick Desaulniers
2021-05-01 0:40 ` Nick Desaulniers
2021-05-01 1:22 ` Linus Torvalds
2021-05-01 1:48 ` Nick Desaulniers
2021-05-01 2:16 ` Fangrui Song
2021-05-01 3:32 ` Tom Stellard
2021-05-01 16:32 ` Linus Torvalds
2021-05-01 19:57 ` Serge Guelton
2021-05-01 22:39 ` Linus Torvalds
2021-05-01 23:55 ` Fangrui Song
2021-05-01 21:58 ` David Laight [this message]
2021-05-02 9:31 ` Adrian Bunk
2021-05-02 11:35 ` David Laight
2021-05-02 16:12 ` Linus Torvalds
2021-05-02 16:45 ` Adrian Bunk
2021-05-02 16:49 ` Linus Torvalds
2021-05-02 17:55 ` Adrian Bunk
2021-05-02 17:59 ` Linus Torvalds
2021-05-02 21:48 ` Adrian Bunk
2021-05-04 22:02 ` Miguel Ojeda
2021-05-05 0:58 ` Theodore Ts'o
2021-05-05 17:21 ` Miguel Ojeda
2021-05-04 21:32 ` Miguel Ojeda
2021-05-05 11:05 ` David Laight
2021-05-05 13:53 ` Miguel Ojeda
2021-05-05 14:13 ` David Laight
2021-05-05 16:06 ` Miguel Ojeda
2021-05-05 16:25 ` David Laight
2021-05-05 17:55 ` Miguel Ojeda
2021-05-03 1:03 ` Maciej W. Rozycki
2021-05-03 14:38 ` Theodore Ts'o
2021-05-03 14:54 ` Theodore Ts'o
2021-05-03 17:14 ` Maciej W. Rozycki
2021-05-03 16:09 ` David Laight
2021-05-04 23:04 ` Greg Stark
2021-05-05 0:55 ` Theodore Ts'o
2021-05-01 23:37 ` Mike Hommey
2021-05-02 5:19 ` Dan Aloni
2021-05-03 16:48 ` Tom Stellard
2021-05-03 19:00 ` Fangrui Song
2021-04-30 0:52 ` Nathan Chancellor
2021-04-30 2:21 ` Nick Desaulniers
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).