On Tue, Feb 25, 2020 at 3:07 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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@xxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
