How Intel's Clear Linux Team Cut The Kernel Boot Time From 3 Seconds To 300 ms

[sofar]

I notice they are using systemd-bootchart, have they contributed anything back?
It was in the systemd tree from 197 to 230, and has been unmaintained since.

It's still maintained, but at a different pace than systemd - after all it's a fairly simple diagnostic tool. Source: I wrote it.

[SystemCrasher]

The problem is that by doing this they'll be dropping compatibility with e.g. BIOS. Yes, BIOS still requires 16-bit mode at the beginning and I'm pretty sure even UEFI does too (but initializes a 64-bit environment fairly quickly).

Ironically, UEFI can't even boot DOS on its own. Nor it would work without BIOS fallback that also inits VGA, pretends AHCI is some kind of IDE, exposes USB ... and actually most of recent hardware stopped doing so or does it fairly buggy. And then, DOS and its apps (and maybe few win3.1x 16-bit apps) are the only reason to bother about 16-bit. So its really archaic, b0rkz0r3d architecture - and compatibility with it is a lot of pain with little to no gain (does someone really going to use DOS or Win3.1 apps?). I wouldn't miss it for sure, just because there is only one arch/command set worse than that I know (Microchip PIC).

And once we're here, it can be good idea to take opportunity to learn from past mistakes. Something that wintel never managed to do, ending up plagued with overgrown booog3d crap firmwares that nobody going to fix, ever. Only barely tested with certain version of windows - and total disaster everywhere else. To extent some laptops would brick on OS reinstall, screwing NVM area the way firmware goes nuts and can't boot anymore. UEFI is almost OS on its own - intrusive, proprietary and vendors only caring of windows (or to be exact, certain version of it they preinstall).

If someone doubts: read dmesg on most of x86 hardware. Be it BIOS or UEFI, ACPI or so, it usually goes with ton of bugs, non-standard quirks and so on. This inevitably warrants shitty experience if you not excited about very certain win version. In best case bugs wouldn't be annoying. In worst, they would bite. And nobody would ever fix that. Esp for Linux.

That's where Intel can go fsck self with all their boot times together. Their major problem is insane system complexity and inclination on proprietary crap, backdoor-like features (ME, Bootguard, SMM, etc) and so on. At which point using Intel where 0.3 second boot time makes sense (control, automation, devices, ...) inevitably ends being perilous task. And if all these concerns addressed, it makes hell a lot of sense also grab modern cpu core design without tons of legacy and do very same for "chip set" (even if it integrated to same IC) and so on. This simplifies system design a lot and makes it far more robust and bug-free.

[Ronshere]

Do you know that the "Linux team" would include microsoft, as they are a pretty big contributor to Linux? You knew that right?

I suspect that MS Winux is the future

[lsatenstein]

Intel should maybe look at UEFI first, that beast wastes 30 seconds on my normal desktop systems! Even if my kernel would need 5 seconds to boot instead of 3, I wouldn't even notice this difference!

On my ASUS X470 system, the bios takes more time to load grub, than actually loading Fedora31. My main boot is an m.2 nvme drive I then cloned Fedora31 to an SSD. Boot time was significantly reduced.
Upon investigation, fstrim does not like to work against active mounted drives (eg / ). I did do a cleanup and removed 4 months of free'd blocks. (4 gigs)
The 1 TB nvme has 600 gigs free before and after. The nvme is a triple level bit store.

For the Windows fanboy, MS is moving more of it's stuff to Linux and while the user interface will remain more or less unchanged, under the covers, the compiler and host will eventually be Linux.

MS has to fear ClearLinux. Intel is there to protect it's hardware sales. Foundries are offering to build tailored cpus that will do away with the need for some software vendors to useINTEL/AMD/other