veyepar: Booting faster

Author(s):	Stewart Smith
Location	C1
Date	jan Wed 23	Days Raw Files
Start	11:35	First Raw Start	11:23
Duration	0:45:0	Offset	0:11:38
End	12:20	Last Raw End	12:27
Chapters	00:00 0:28:15 0:34:21
Total cuts_time	47 min.

https://2019.linux.conf.au/schedule/presentation/105/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf Booting_faster.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Doing kernel and firmware development leaves you rebooting computers a lot. Modern computers (especially servers) take too long to boot. Since OpenPOWER systems have a fully open firmware stack (some even with an open BMC stack), we can now attack the problem from all angles. This talk covers efforts over the past several years into making POWER based systems boot faster. Is it Linux itself that takes the most time? Firmware? What part of firmware and why? Are the problems for a single socket desktop system different to those from an 8 socket enterprise one? Where have we gotten worse and why? Can we go from close to 10 minutes to less than 30 seconds? 10 seconds? At what point are we purely limited by peoples unreasonable expectations of having PCI, RAM, and output on a display? We go on a full stack deep dive into what it takes to cold (and warm) boot (and reboot) a system - or at least any part of that which takes time, as well as how we've measured it. We'll touch on code before the power button works, code from before the first instruction is executed, and code all the way up to being able to load a kernel off disk and beyond. When talking about future improvements, anyone stating "but you're already faster than a bunch of our other servers" will be subtly ssshhed. markdown
Comment:	production notes