Tails

#1 Updated by intrigeri 2018-11-17 18:44:31

Our work on Feature #15292 will deprecate booting from DVD except for VMs, where readahead does not matter much (or at all): most Linux distros have no such mechanism when booting from the hard disk, which is effectively the case when booting a VM from an ISO stored on a hard disk. So I’ll skip the measurement part and directly remove all readahead.

#2 Updated by intrigeri 2018-11-17 18:52:09

And I’ll also remove the SquashFS sort system: it’s not particularly useful when booting from a USB stick, increases the cost of releasing Tails, and is useless for VMs.

#5 Updated by intrigeri 2018-11-17 21:05:40

Note to myself: pay attention to reproducibility (who knows, maybe the sort file is actually a key factor of building the SquashFS reproducibly?)

#7 Updated by intrigeri 2018-11-18 19:58:38

ThinkPad X200, USB:

• baseline (readahead + SquashFS sort file): 96s to the Greeter + 25s to the GNOME desktop
• no readahead, no SquashFS sort file: 128s to the Greeter + 42s to the GNOME desktop

=> one of these 2 things is definitely useful. I’ll find out which one.

Speculating — if it’s the readahead, then let’s keep it for now and reconsider once we ship a pre-compiled AppArmor policy (aka. binary cache): most of the benefit of the readahead is gained while the boot is blocked by CPU-bounds tasks that don’t use much I/O; at the moment, on not-super-fast machines, I suspect this is dominated by apparmor.service compiling the policy; once we remove that big CPU-bound blocker from the boot process, it may be that the readahead won’t be of much use anymore.

#8 Updated by intrigeri 2018-11-19 08:28:08

ThinkPad X200, USB:

• baseline (readahead + SquashFS sort file): 96s to the Greeter + 25s to the GNOME desktop
• no readahead, no SquashFS sort file: 128s to the Greeter + 42s to the GNOME desktop
• no readahead, SquashFS sort file: 85s to the Greeter + 25s to the GNOME desktop

The results I see in VMs on my system (ISO backed with by pretty fast NVMe) and in the test suite (another machine, pretty fast NVMe as well) are mostly consistent with those: the only exception is that there’s no statistically significant improvement when removing only the readahead.

Conclusions:

• sorting the SquashFS is very useful even when booting from bare metal USB or from an ISO backed by fast storage => let’s keep it, even though it has a cost (takes time during the release process which increases our time to remediation, decreases the chances we put out emergency releases, and costs us money)
• the readahead is detrimental when booting from bare metal USB and useless when booting from an ISO backed by fast storage => let’s drop it, save 10s of boot time on a typical laptop, and make our code simpler :)

(Oh, and to whoever might be wondering: as indicated by the fact this does not block any FT tracking ticket, I’m doing this as a volunteer, for fun, without clocking, purely as pleasurable procrastination, even though it might results in minor improvements to our “Make it easier to switch between a Tails contextual identity and another identity outside of Tails” strategic planning goal :)

#9 Updated by intrigeri 2018-11-30 15:48:24

I’ve not checked in depth but it seems that this branch has failures on Jenkins that I’m not used to see there. I don’t know if that’s a bug in our test suite which would be usually not be triggered, or a “real” regression caused by this branch.