Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lsatenstein
    replied
    Originally posted by R41N3R View Post
    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

    Leave a comment:


  • Ronshere
    replied
    Originally posted by ZeroPointEnergy View Post
    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

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by tildearrow View Post

    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.

    Leave a comment:


  • sofar
    replied
    Originally posted by Tobu View Post
    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by polarathene View Post

    Mine will disable the feature if it boots unsuccessfully 3 times iirc. Don't have to pop out the CMOS battery, personally easier to just detach the OS disk(s) by unplugging the SATA cables.
    Of course modern machines like mine use NVMe disks instead. You'd have to unscrew a bolt. On my other system the NVMe disk happens to be located on the backside of the mobo so unscrewing that requires unassembling the whole mobo and all PCIe cards.

    I think it might prevent USB stick(or other storage) from being bootable option though, if not then having that as a higher priority when plugged in could work for recovery.
    Ok that might work.

    Really though, it's barely an important time savings as I rarely reboot(Once every few months usually), so I just don't see much point in it myself.
    Fair enough. I reboot daily and would really love faster boot time. I'm pretty sure my old Haswell machine actually booted faster than the current one, which is funny cause the old board was full size ATX board with all the bells and whistles (i.e. more firmware to set up during boot) while the current board is mATX. The current board also uses faster RAM, faster disks etc. But still boots slower.

    Leave a comment:


  • geearf
    replied
    Originally posted by sb56637 View Post

    Maybe something like the old Mandriva installer approach of offering to remove unneeded hardware drivers during installation? The live/install media could use a bloated everything-and-the-kitchen-sink kernel + drivers, and then pare it down automatically based on what hardware it's installed on. Although this would have the disadvantage of removing Linux's hardware agnosticism where you can normally pull the root disk out of a machine and pop it in another and usually expect it to boot like nothing happened.

    As for broken hardware devices that requires dirty hacks, yeah, that one sounds harder to work around.
    Since storage is not the issue, instead of that you could offer 2 kernels, one standard with all needed and one trimmed. You'd usually use the trimmed one, unless it fails then you'd switch to the other. It's the same thing that is done today with trimmed and full initrd.

    Leave a comment:


  • sb56637
    replied
    Originally posted by F.Ultra View Post

    and removing lots of kernel modules that they have no use for, note that this is a tailored installation where they know exactly what hardware that will exist at all times so not everything that they have done here can be applied to a generic desktop distribution. Then there is the problem which they stated in the PDF that lots of drivers use large timeouts to handle various pieces of broken hardware out there.
    Maybe something like the old Mandriva installer approach of offering to remove unneeded hardware drivers during installation? The live/install media could use a bloated everything-and-the-kitchen-sink kernel + drivers, and then pare it down automatically based on what hardware it's installed on. Although this would have the disadvantage of removing Linux's hardware agnosticism where you can normally pull the root disk out of a machine and pop it in another and usually expect it to boot like nothing happened.

    As for broken hardware devices that requires dirty hacks, yeah, that one sounds harder to work around.

    Leave a comment:


  • aht0
    replied
    It's probably because both languages, English & Chinese, have over a billion users and so both would receive immense amount of fixes.

    Example: "Auto sõitis ristmikul hunnikusse"
    Real meaning: Car got wrecked on intersection.

    Feel free to check how Google Translate sees that. I'll note there's also meaningful difference between junction and intersection. It can't get even short random sentence mostly right, not to mention choosing correct terms. It becomes exponentially worse when dealing with synonymes and contextual differences in longer actual texts. Doing couple of translations back and forth ends up as completely incomprehensible bs .
    Last edited by aht0; 13 September 2019, 04:39 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by aht0 View Post
    Google Translate frankly sucks. At least when you are translating between major/minor languages
    It works decently for English-> something or the reverse.

    I've had better results with X -> english -> Y than with X-> Y directly. It's still kinda broken and open to interpretation, but at least it's usable.

    On Chinese -> english it's decent too, especially the "translate what my camera sees".

    Leave a comment:


  • aht0
    replied
    Originally posted by DanL View Post

    If your English is not the best, then maybe you can write in your native language and auto-translate it for us.
    Google Translate frankly sucks. At least when you are translating between major/minor languages (by amount of speakers worldwide) and/or languages which lack linguistic relation. Examples: Germanic and non-Germanic languages (Germanic/Fenno-Ugric, Germanic/Slavic).
    ​​​Output is often anywhere from garbage quality to being incomprehensible.

    So if his native happens to be something non-Germanic, spoken by million or two, however crappy his English, it would be more understandable than copy-paste from Google Translate could ever be.

    Leave a comment:

Working...
X