Announcement

Collapse
No announcement yet.

x86 Systems Will See Some Boot Time Optimizations With Linux 4.3

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

  • x86 Systems Will See Some Boot Time Optimizations With Linux 4.3

    Phoronix: x86 Systems Will See Some Boot Time Optimizations With Linux 4.3

    Ingo Molnar sent in his several Git pull requests today for the code he maintains within the Linux kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    x64 no boot time optimization.

    Comment


    • #3
      Code:
      148ms (loader) + 343ms (kernel) + 598ms (initrd)
      I am not sure how the could make it faster .

      Comment


      • #4
        So 0.7ms speed improvement. If I boot my computer 3 times a day, then I will have saved 0.8 seconds cumulatively in a year! Not really worth writing home about, let alone writing a Phoronix story about .

        Comment


        • #5
          Well, it's not so much about the individual and/or total time improvements as much as it is about the intention behind it, I think. Continued optimization on a low level; this process has been ongoing ever since 4.0 and seems to continue on. Personally, I am quite excited by this latest development. Sure, at face value it may not mean much but the thought behind it I'm all for. Lots of stuff in the kernel that needs to be brought to the 2nd decade of the 21st century.

          Comment


          • #6
            Originally posted by Thue View Post
            So 0.7ms speed improvement. If I boot my computer 3 times a day, then I will have saved 0.8 seconds cumulatively in a year! Not really worth writing home about, let alone writing a Phoronix story about .

            While your comment makes sense, try to think of the bigger picture: Yes, for a regular consumer computer/device, this basically has no impact, as your clever example showed. But as soon as you start thinking about use cases where high availability is key, every ms saved counts.

            Comment


            • #7
              Originally posted by dragonn View Post
              Code:
              148ms (loader) + 343ms (kernel) + 598ms (initrd)
              I am not sure how the could make it faster .
              If you want it faster, directly boot kernel from the beginning of the disk without any special boot loader. initrd isn't necessary unless you load early microcode. I'd just compile in everything if speed is crucial. The userspace can be further optimized. Use squashfs with correct block size and all optimizations, statically compile with musl. Use LTO everywhere.

              Comment


              • #8
                I wonder if this optimisation has anything to do with CoreOS, Rockets and Intel booting VMs in it - https://coreos.com/blog/rkt-0.8-with-new-vm-support/

                If you are spinning up a shed load of containers then I am sure it will make sense to shave as much time as possible of bootups

                Comment


                • #9
                  Originally posted by Thue View Post
                  So 0.7ms speed improvement. If I boot my computer 3 times a day, then I will have saved 0.8 seconds cumulatively in a year! Not really worth writing home about, let alone writing a Phoronix story about .
                  No...
                  148+343+598 = 1089ms
                  1089ms = 1.089s

                  So it's saving 1 second per boot...

                  Comment


                  • #10
                    Originally posted by naoliv View Post

                    No...
                    148+343+598 = 1089ms
                    1089ms = 1.089s

                    So it's saving 1 second per boot...
                    1000 microseconds in 1 millisecond. 1000 milliseconds in 1 second. The article mentioned a total of 700 microseconds gained. So, Thue was right.

                    Anyway, though 0.7ms is pretty negligible (especially for x86) any improvement is welcome. But, it makes me wonder why those delays were there in the first place.
                    Last edited by schmidtbag; 31 August 2015, 10:26 PM.

                    Comment

                    Working...
                    X