[systemd-devel] Minimize systemd for kdump's initramfs

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote:
> On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > > On 01/03/20 at 11:45am, Dave Young wrote:
> > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > > > the size of part of binaries along with the binaries they required in
> > > > > > F31:
> > > > > > /root/image/bin/systemctl
> > > > > > 20M     .
> > > > > > /root/image/usr/bin/systemctl
> > > > > > 20M     .
> > > > > > /root/image/usr/bin/systemd-cgls
> > > > > > 20M     .
> > > > > > /root/image/usr/bin/systemd-escape
> > > > > > 20M     .
> > > > > > /root/image/usr/bin/systemd-run
> > > > > > 20M     .
> > > > > > ...
> > > > > >
> > > > > > There are overlays between the libraries they used so when installed
> > > > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > > > see the size of systemd binary and libraries it used is much bigger
> > > > > > than others.
> > > > >
> > > > > All systemd binaries will mostly link to the same libraries (because
> > > > > they link to a private shared library, which links to various other
> > > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > > it's the same dependencies.
> > > > >
> > > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > > not that much...
> > > > >
> > > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > > dependency increased a lot:
> > > > > > (v219 is 5M in total, v243 is 20M in total)
> > > > >
> > > > > This is slightly misleading. Code was moved from individual binaries
> > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> > > > > more deps). But the total number of deps when summed over all binaries
> > > > > grew much less. A more useful measure would be the size with deps summed
> > > > > over all systemd binaries that are installed into your image in v219 and
> > > > > v243.
> > > > >
> > > >
> > > > I vaguely remember the size increased before due to linking with libidn2
> > > > previously, so those libraries contribute a lot.
> > > >
> > > > Does every systemd binary depend on all libraries? Or each of the
> > > > systemd binary only depends on those libs when really needed?
> > >
> > > For example if I do not need journalctl, then I can drop journalctl and
> > > those libraries specific for journalctl?
> >
> > It's using standard shared object linking, so yeah, for anything which
> > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> > all libraries", in the sense that the runtime linker will fail to start
> > the executable if any of the libraries are missing.
> >
> 
> Hi, it has been a while since last discuss update, but a second
> thought about the libsystemd-shared-nnn.so problem:
> 
> Now each systemd executable depends on libsystemd-shared-nnn.so, which
> then depend on a lot of things. In older version (eg. version 219),
> each individual systemd executable have it's own dependency, that make
> thing much cleaner for special usages like kdump.
> 
> I'm not sure what is the purpose of this change, could there be any
> work be done to minimize the lib dependency of each systemd binary?

libsystemd-shared-nnn.so holds code used in multiple executables. This
means that if the full suite is installed, shared code is present in
just one copy, and the total footprint of the installation is minimized
(disk, loading time, rss). OTOH, the footprint of installing just a
single executable is unfortunately increased. Our thinking was that
installing many executables is much more common (pretty even a minimal
system with systemd has at least ~30 systemd binaries), so it makes
sense to prioritize that.

See https://github.com/systemd/systemd/pull/3516 for the discussion
of the space savings back when this was originally done. Now we have
many more binaries (and even more shared code since integration of
various components is increasing...), so I expect the savings to
be even bigger.

Zbyszek