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

[Kairui Song]

On Tue, Feb 25, 2020 at 3:07 PM Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
>
> 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.

Yes, that's very true, this kind of usage (single binary intallation)
is quite rare.

>
> 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
>

Thanks for the info, the PR reference is very useful. Will check it
for more background knowledge.

-- 
Best Regards,
Kairui Song