It’s all a bit quiet around Fedoraland today with U.S. Thanksgiving happening. So I took some hours out today to do some comparisons of a few key things between a bunch of Fedora releases: 13, 15, 17, 19 and 20. Let’s take a look at the numbers, Jim! All the raw data is available here.
For every release, I used the same KVM VM (specced with 2 CPUs and 2GB of RAM), running on a Fedora 20 host. For Fedora 13 I used cirrus graphics with VNC (the old default), as it cannot handle qxl/SPICE; for all the others I used qxl/SPICE. I did an install using all default choices from the DVD image. Fedora 20 used Final TC3, all others were Final releases.
‘free’-reported memory in use from console after boot to runlevel 3
‘free’-reported memory in use from GNOME terminal after boot to runlevel 5, create user, log in
We can see that the memory used when you simply boot to a console and log in has changed very little all the way back to Fedora 13, released 2010-05-25. We’re doing a fairly good job of keeping our base system from bloating excessively. 19 and 20 are both 30MB worse than 17, but then, 17 was 25MB better than 15.
UPDATE 2013-12-03: Note regarding the following section about GNOME’s memory use: the situation may be more complex than it seems. Testing on bare metal does not produce the same results as testing in a VM, and the use of llvmpipe-based software rendering in the VM may be throwing the numbers off; it’s possible F20 isn’t significantly worse than F19 in this respect after all. See this post.
The same certainly doesn’t hold true for the graphical desktop, though. Just sitting at a mostly-idle desktop with a terminal open, our memory usage has gone from 275MB under the ancien GNOME 2 regime to 300MB with GNOME 3’s ‘fallback mode’ (which was more or less GNOME 2), then rocketed to nearly 400MB, 535MB, and nearly 700MB in subsequent releases. I haven’t yet looked in detail at the changes, but I did take screenshots of ‘top’ ordered by memory usage for each install.
Fedora 13: Xorg 24M, gnote 21M, python 19M, nautilus 17M, gnome-panel 16M, clock-applet 15M, wmck-applet 13M…
Fedora 15: Xorg 53M, systemd 22M, gnome-settings-daemon 18M, clock-applet 15M, gnome-panel 15M, gnome-session 14M, gnome-terminal 14M, wnck-applet 12M…
Fedora 17: gnome-shell 115M, Xorg 53M, systemd 24M, gnome-settings-daemon 21M, gjs-console 19M, gnome-terminal 17M, tracker-store 16M, libsocialweb-something 16M, goa-daemon 15M, nm-applet 14M…
Fedora 19: gnome-shell 160M, Xorg 26M, evolution-data-server 26M/25M/23M/22M (4 processes), gnome-settings-daemon 22M, goa-daemon 22M, gnome-shell 20M, firewalld 20M, libvirtd 18M, gnome-terminal 18M, tracker-store 17M…
Fedora 20: gnome-shell 328M(!), evolution-data-server 56M/28M/22M (3 processes), gnome-settings-daemon 30M, Xorg 26M, systemd-journald 22M, gnome-shell 21M, firewalld 21M, goa-daemon 20M, gnome-terminal 19M, libvirtd 19M, tracker-store 17M…
these are all the raw ‘RES’ numbers, which don’t really tell the whole story, but they’re close enough for a ballpark. The obvious things that jump out are that we don’t really see the memory usage of particular elements of the desktop increasing over time – where the same processes occur in multiple releases, memory usage is usually pretty similar – but GNOME seems to be running more and more stuff by default over time (there’s a couple of new basesystem bits too, but we can tell from the runlevel 3 numbers that the net impact there is small), some of it adding significantly to the memory burden. GNOME 3 is also clearly heavier than GNOME 2. The obvious big exception is that the memory usage of the Shell itself grew massively – in fact, more than doubled – from Fedora 19 to Fedora 20, accounting for all the overall increase in memory usage from 19 to 20 by itself. gnome-settings-daemon has also been growing on a more modest scale, from 18MB at F15 to 30MB in F20.
I don’t know if anyone in GNOME land is focused on efficiency, but these numbers suggest that it might be a good idea to spend some time on it. Some of the increase is probably unavoidable with GNOME’s increase in capabilities over time, but some of it is probably fixable.
Size of installed system
Well, nothing much interesting going on there.
Loaded services at runlevel 3
Seems like we were gradually reducing the number of services loaded at boot from 15 through 19, then reversed course for 20. This is one where the raw numbers are a blunt instrument, though, and you have to look at details. Manually comparing the 19 and 20 lists doesn’t reveal any huge oddities; it’s mostly just that more things which were happening at startup anyway appear as discrete systemd units now. One that does seem a little odd is that 19 did not have ModemManager.service running by default, but 20 does.
It’s kinda fun to diff the default package set from release to release; I saved a full list of packages installed (without versions) in each release.
There’s a lot of detail in there, of course. For fun, here is a diff between the Fedora 13 and Fedora 20 package sets. A bit more usefully, here is a diff between the Fedora 19 and Fedora 20 package sets. The additions in 20 look to be kinda split between new functionality and added deps for existing things.
Fedora 13: kernel 3.5MB, initramfs 123MB
Fedora 15: kernel 3.9MB, initramfs 147MB
Fedora 17: kernel 4.7MB, initramfs 174MB
Fedora 19: kernel 5.1MB, initramfs (generic) 266MB, initramfs (stripped) 118MB
Fedora 20: kernel 5.1MB, initramfs (generic) 376MB, initramfs (stripped) 121MB
In F18 or F19 (I forget which) we stopped using a generic initramfs – one with every possible thing in it – by default, and started stripping the initramfs to contain only stuff needed for the installed system. We install a ‘rescue’ initramfs (and boot menu entry) which is generic at install time, so if you change your system’s hardware in a way that the stripped initramfs can’t cope with, you have something to boot from to generate a new stripped initramfs. That’s what the “generic” and “stripped” numbers are. As we can see, the kernel+initramfs have sure gotten bigger over time; I’m not qualified to speculate on how much is additional capability and how much is bloat, but it might have been nice to compare an ‘lsinitrd’ for each release (unfortunately, I didn’t think to save one). The ‘stripped’ initramfs plan was a bit controversial, but these numbers at least illustrate that it certainly serves a need. Remember, the initramfs is loaded into memory at boot time, so these numbers translate directly into unavoidable memory consumption for the booted system. It’s interesting that F20’s generic (rescue) initramfs is so much larger than F19’s.
Only have numbers for 19 and 20 here, as systemd’s handy-dandy ‘analyze’ capability didn’t exist for 17 and earlier, and I wasn’t going to bother manually doing bootchart.
20 got a second or so faster than 19, which is nice. Both are pretty snappy. Of course, I’m running on a host with lots of RAM. The guest disk images are stored on my fairly fast NAS.
Installer memory consumption
For 17, 19 and 20 I ran the installer memory profiler that Chris Lumens wrote and I blogged about before. Here are the charts.
The broad shapes of each graph are very similar; it’s obvious that there haven’t been really major changes in the way the installer uses memory between these releases. We did kill the thing that generated the huge peaks early in install in Fedora 17 (it was an SELinux policy thing, IIRC). The later peaks in all three graphs are packages running gtk-update-icon-cache and update-mime-database in their %post or %posttrans. It’s somewhat interesting that the peaks seem to flatten out at the tops in the F20 graph, but I don’t know yet what’s behind that exactly.
Fedora 20 is slightly heavier on memory usage than F19 was overall. There is no obvious smoking gun behind this, though – as noted, the overall shapes of the graphs are very similar. Fedora 19’s installer initramfs is 328MB, Fedora 20’s is 343MB; this probably accounts for 15MB of the difference. The absolute peak usage for Fedora 19 is 704156 (704MB) during the last gtk-update-icon-cache run (the previous one hits 703780), for Fedora 20 is 775364 (775MB) during the second-to-last gtk-update-icon-cache run (the last hits 761724). Right after the final gtk-update-icon-cache run, and before the gradual ramp-up in usage that happens during yum’s ‘verification’ step, F19 is at 583MB, F20 is at 642MB. So that’s about 60MB, minus the 15MB initramfs, that’s gone somewhere between 19 and 20.
So…there’s a bunch of data, I guess. =) Hope it was interesting!